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CHAPTER  1 


INTRODUCTION 


This  Validation  Suomary  Report  deacrlbes  the  extent  to  which  a 

specific  Ada  compiler  conforms  to  the  Ada  Standard,  ANSI/MIL-STD-1815A. 
This  report  explains  all  technical  terms  used  within  it  and  thoroughly 
reports  the^  results  oT  testing  this  compiler  using  the  Ada  Compiler 
Validation  Capability  I  An  Ada  compiler  must  be  implemented 

according  to  the  Ada  Standard,  and  any  implementation>dependent  features 
must  conform  to  the  requirements  of  the  Ada  Standard.  The  Ada  Standard 
must  be  implemented  in  its  entirety,  and  nothing  can  be  implemented  that  is 
not  in  the  Standard. N 
- — - - 

Even  though  all  validated  Ada  compilers  conform  to  the  Ada  Standard,  it 
must  be  understood  that  some  differences  do  exist  between  implementations. 
The  Ada  Standard  permits  some  implementation  dependencies— .for  example,  the 
maximum  length  of  identifiers  or  the  maximum  values  of  integer  types. 
Other  differences  between  compilers  result  from  the  characteristics  of 
particular  operating  systems,  hardware,  or  implementation  strategies.  All 
the  dependencies  observed  during  the  process  of  testing  this  compiler  are 
^iven  in  thla  report,  ^ 

The  information  in  this  report  is  derived  from  the  test  results  produced 
during  validation  testing.  The  validation  process  includes  submitting  a 
suite  of  standardized  tests,  the  ACVC,  as  inputs  to  an  Ada  compiler  and 
evaluating  the  results .  \  The  purpose  of  validating  is  to  ensure  conformity 
of  the  compiler  to  the  Ada’  Standard  by  testing  that  the  compiler  properly 
implements  legal  language  constructs  and  that  it  identifies  and  rejects 
illegal  language  constructs.  The  testing  also  identifies  behavior  that  is 
implementation  dependent  but  permitted  by  the  Ada  Standard.  Six  classes  of 
tests  are  used.  These  tests  are  designed  to  perform  checks  at  compile 
time,  at  link  time,  and  during  execution. 
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1 . 1  PURPOSE  OF  THIS  VALIDATION  SUMMARY  REPORT 

This  VSR  documenta  the  results  of  the  validation  testing  performed  on  an 
Ada  compiler.  Testing  was  carried  out  for  the  following  purposes: 

.  To  attempt  to  identify  any  language  constructs  supported  by  the 
compiler  that  do  not  conform  to  the  Ada  Standard 

.  To  attempt  to  identify  any  language  constructs  not  supported  by 
the  compiler  but  required  by  the  Ada  Standard 

.  To  determine  that  the  implementation-dependent  behavior  is  allowed 
by  the  Ada  Standard 


Testing  of  this  compiler  was  conducted  by  SofTech,  Inc.  under  the 
direction  of  the  AVF  according  to  procedures  established  by  the  Ada  Joint 
Program  Office  and  administered  by  the  Ada  Validation  Organization  (AVO). 
On-site  testing  was  completed  04  MAY  88  at  Hewlett  Packard,  Cupertino,  CA. 


1.2  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  AVO  may 
make  full  and  free  public  disclosure  of  this  report.  In  the  United  States, 
this  is  provided  in  accordance  with  the  "Freedom  of  Information  Act"  (5 
U.S.C.  #552).  The  results  of  this  validation  apply  only  to  the  computers, 
operating  systems,  and  compiler  versions  identified  in  this  report. 

The  organizations  represented  on  the  signature  page  of  this  report  do  not 
represent  or  warrant  that  all  statements  set  forth  in  this  report  are 
accurate  and  complete,  or  that  the  subject  compiler  has  no  nonconformities 
to  the  Ada  Standard  other  than  those  presented.  Copies  of  this  report  are 
available  to  the  public  from: 

Ada  Information  Clearinghouse 
Ada  Joint  Program  Office 
OUSDRE 

The  Pentagon,  Rm  3D- 139  (Fern  Street) 

Washington  DC  20301-3081 


or  from: 


Ada  Validation  Facility 
ASD/SCEL 

Wright-Patterson  AFB  OH  "5433-6503 
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Questions  regarding  this  report  or  the  validation  test  results  should  be 
directed  to  the  AVF  listed  above  or  tot 

Ada  Validation  Organization 
Institute  for  Defense  Analyses 
1801  North  Beauregard  Street 
Alexandria  VA  2231 1 


1.3  REFERENCES 


1 .  Reference  Manual  for  the  Ada  Prograaming  Language, 
AMSI/MIL-STD-1815A,  February  1983  and  ISO  8652-1987. 

2.  Ada  Compiler  Validation  Procedures  and  Guidelines .  Ada  Joint 
Program  Office,  1  January  1987. 

3.  Ada  Compiler  Validation  Capability  Implement era  *  Guide,  SofTech, 
Inc.,  December  1986. 

4.  Ada  Compiler  Validation  Capability  User’s  Guide,  December  1986, 
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1.4  DEFINITION  OF  TERMS 


ACVC  The  Ada  Compiler  Validation  Capability.  The  set  of  Ada 

programs  that  tests  the  conformity  of  an  Ada  compiler  to  the 
Ada  programming  language. 

Ada  An  Ada  Coonentary  contains  all  Information  relevant  to  the 

Commentai*y  point  addressed  by  a  comment  on  the  Ada  Standard.  These 

comments  are  given  a  unique  Identification  number  having  the 
form  Al-ddddd. 

Ada  Standard  ANSI/MIL-STD-1815A,  February  1983  and  ISO  8652-1987. 

Applicant  The  agency  requesting  validation. 

AVF  The  Ada  Validation  Facility.  The  AVF  is  responsible  for 

conducting  compiler  validations  according  to  procedures 
contained  in  the  Ada  Compiler  Validation  Procedures  and 
Guidelines . 

AVO  The  Ada  Validation  Organization.  The  AVO  has  oversight 

authority  over  all  AVF  practices  for  the  purpose  of 
maintaining  a  uniform  process  for  validation  of  Ada 
compilers.  The  AVO  provides  administrative  and  technical 
support  for  Ada  validations  to  ensure  consistent  practices. 

Compiler  A  processor  for  the  Ada  language.  In  the  context  of  this 

report,  a  compiler  is  any  language  processor,  Including 
cross-compilers,  translators,  and  interpreters. 

Failed  test  An  ACVC  test  for  which  the  compiler  generates  a  result  that 

demonstrates  nonconformity  to  the  Ada  Stwdard. 

Host  The  computer  on  which  the  compiler  resides. 

Inapplicable  An  ACVC  test  that  uses  features  of  the  language  that  a 

test  compiler  Is  not  required  to  support  or  may  legitimately 

support  In  a  way  other  than  the  one  expected  by  the  test. 

Passed  test  An  ACVC  test  for  which  a  compiler  generates  the  expected 

result . 

Target  The  computer  for  which  a  compiler  generates  code. 

Test  A  program  that  checks  a  compiler's  conformity  regarding  a 

particular  feature  or  a  combination  of  features  to  the  Ada 
Standard.  In  the  context  of  this  report,  the  term  is  used  to 
designate  a  single  test,  which  may  comprise  one  or  more 
files. 

Withdrawn  An  ACVC  test  found  to  be  incorrect  and  not  used  to  check 

test  conformity  to  the  Ada  Stemdard.  A  test  may  be  incorrect 
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because  it  has  an  invalid  test  objective,  fails  to  meet  its 
test  objective,  or  contains  illegal  or  erroneous  use  of  the 
language. 


1.5  ACVC  TEST  CLASSES 

Conformity  to  the  Ada  Standard  is  measured  using  the  ACVC.  The  ACVC 
contains  both  leg^  and  illegal  Ada  programs  structvired  into  six  test 
classes:  A,  B,  C,  D,  E,  and  L.  The  first  letter  of  a  test  name  identifies 
the  class  to  which  it  Xiongs.  Class  A,  C,  D,  and  E  tests  are  executable, 
and  special  program  units  are  used  to  report  their  results  during 
e:ncutlon.  Class  B  tests  are  expected  to  produce  compilation  errors. 
Class  L  tests  are  expected  to  produce  conpilatlon  or  link  errors. 

Class  A  testa  check  that  legal  Ada  programs  can  be  successfully  compiled 
and  executed.  There  are  no  explicit  program  components  in  a  Class  A  test 
to  check  semantics.  For  example,  a  Class  A  test  checks  that  reserved  words 
of  another  language  (other  than  those  already  reserved  in  the  Ada  language) 
are  not  treated  as  reserved  words  by  an  Ada  compiler.  A  Class  A  test  is 
passed  if  no  errors  are  detected  at  compile  time  and  the  program  executes 
to  produce  a  PASSED  message. 

Class  B  testa  check  that  a  compiler  detects  illegal  language  usage.  Class 
B  tests  are  not  executable.  Each  test  in  this  class  is  compiled  and  the 
resulting  compilation  listing  is  examined  to  verify  that  every  syntax  or 
semantic  error  in  the  test  is  detected.  A  Class  B  test  is  passed  if  every 
illegal  construct  that  it  contains  is  detected  by  the  compiler. 

Claiss  C  tests  check  that  legal  Ada  programs  can  be  correctly  compiled  and 
executed.  Each  Class  C  test  is  self-checking  and  produces  a  PASSED, 
FAILED,  or  NOT  APPLICABLE  message  Indicating  the  result  when  it  is 
e:»cuted . 

Class  D  tests  check  the  compilation  and  execution  capacities  of  a  compiler. 
Since  there  are  no  capacity  requirements  placed  on  a  compiler  by  the  Ada 
Standard  for  some  parameters--for  example,  the  number  of  identifiers 
permitted  in  a  compilation  or  the  number  of  units  in  a  librau"y--a  compiler 
may  refuse  to  compile  a  Class  D  test  and  still  be  a  conforming  compiler. 
Therefore,  if  a  Class  D  test  fails  to  compile  because  the  capacity  of  the 
compiler  is  exceeded,  the  test  is  classified  as  inapplicable.  If  a  Class  D 
test  compiles  successfully,  it  is  self-checking  and  produces  a  PASSED  or 
FAILED  message  during  execution. 

Each  Class  E  test  is  self-checking  and  produces  a  NOT  APPLICABLE,  PASSED, 
or  FAILED  message  when  it  is  compiled  and  executed.  However,  the  Ada 
Standard  permits  an  implementation  to  reject  programs  containing  some 
features  addressed  by  Class  E  tests  during  compilation.  Therefore,  a  Class 
E  test  is  passed  by  a  compiler  if  it  la  compiled  successfully  and  executes 
to  produce  a  PASSED  message,  or  if  it  is  rejected  by  the  compiler  for  an 
allowable  reason. 
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Class  L  tests  check  that  incomplete  or  Illegal  Ada  programs  involving 
multiple,  separately  compiled  units  are  detected  and  not  allowed  to 
execute.  Class  L  tests  are  compiled  separately  and  execution  is  attempted. 
A  Class  L  test  passes  if  it  is  rejected  at  link  time— that  is,  an  attempt 
to  execute  the  main  program  must  generate  an  error  message  before  any 
declarations  in  the  main  program  or  any  units  referenced  by  the  main 
program  are  elaborated. 

Two  librai^  units,  the  package  REPORT  and  the  procedure  CHECK_FILE,  support 
the  self-checking  features  of  the  executable  tests.  The  ^ckage  REPORT 
provides  the  mechanism  by  which  executable  tests  report  PASSED,  FAILED,  or 
HOT  APPLICABLE  results.  It  also  provides  a  set  of  identity  functions  used 
to  defeat  some  compiler  optimizations  allowed  by  the  Ada  Standard  that 
would  circumvent  a  test  objective.  The  procedure  CHECK_FILB  is  used  to 
check  the  contents  of  text  files  written  by  some  of  the  Class  C  tests  for 
chapter  14  of  the  Ada  Standard.  The  operation  of  REPORT  and  CHEC1C_FILE  is 
checked  by  a  set  of  executable  tests.  These  tests  produce  messages  that 
are  examined  to  verify  that  the  units  are  operating  correctly.  If  these 
units  are  not  operating  correctly,  then  the  validation  is  not  attempted. 

The  text  of  the  testa  in  the  ACVC  follow  conventions  that  are  Intended  to 
ensure  that  the  tests  are  reasonably  portable  without  modification.  For 
example,  the  tests  make  use  of  only  the  basic  set  of  53  characters,  contain 
lines  with  a  maximum  length  of  72  characters,  use  small  nuneric  values,  and 
place  features  that  may  not  be  supported  by  all  implementations  in  separate 
tests.  However,  some  tests  contain  values  that  require  the  test  to  be 
customized  according  to  implementation-specific  values— for  example,  an 
illegal  file  name.  A  list  of  the  values  used  for  this  validation  is 
provided  in  ^pendlx  C. 

A  compiler  must  correctly  process  each  of  the  tests  in  the  suite  and 
demonstrate  conformity  to  the  Ada  Standeu'd  by  either  meeting  the  paiss 
criteria  given  for  the  test  or  by  showing  that  the  test  is  inapplicable  to 
the  implementation.  The  applicability  of  a  test  to  an  Implementation  is 
considered  each  time  the  implementation  is  validated.  A  test  that  is 
inapplicable  for  one  validation  is  not  necessarily  inapplicable  for  a 
subsequent  validation.  Any  test  that  was  determined  to  contain  an  illegal 
language  construct  or  an  erroneous  language  construct  is  withdrawn  from  the 
ACVC  and,  therefore,  is  not  used  in  testing  a  compiler.  The  teats 
withdrawn  at  the  time  of  this  validation  aure  given  in  Appendix  D. 
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CHAPTER  2 

CONFIGURATION  INFORMATION 

2.1  CONFIGURATION  TESTED 

The  candidate  compilation  system  for  this  validation  was  tested  under  the 
following  configuration: 

Compiler:  HP  9000  Series  300  Ada  Compiler,  Version  3.25 
ACVC  Version:  1.9 

Certificate  Number:  880429W1. 09050 

Host  Computer: 

Machine:  HP  9000  Series  300  Model  350 

Operating  System:  HP-UX 

Revision  6.01 

Memory  Size:  16  Mbytes 

Tau*get  Computer: 

Machine:  HP  9000  Series  300  Model  350 

Operating  System:  HP-UX 

Revision  6.01 

Memory  Size:  16  Mbytes 
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2.2  IMPLEMENTATION  CHARACTERISTICS 

One  of  the  purposes  of  validating  compilers  Is  to  determine  the  behavior  of 
a  compiler  In  those  areas  of  the  Ada  Standard  that  permit  implementations 
to  differ.  Class  D  and  E  teats  specifically  check  for  such  Implementation 
differences.  However,  tests  In  other  classes  also  chauracterize  am 
Implementation.  The  tests  demonstrate  the  following  characteristics: 


.  Capacities . 

The  compiler  correctly  processes  tests  containing  loop  statements 
nested  to  65  levels,  block  statements  nested  to  65  levels,  and 
recursive  procedures  separately  compiled  as  subunits  nested  to  17 
levels.  It  correctly  processes  a  compilation  containing  723 
variables  In  the  same  declarative  part.  (See  tests  D55A03A. .H  (8 
tests),  D56001B,  D64005E..G  (3  tests),  and  D29002K.) 


.  Universal  Integer  calculations. 

An  Implementation  Is  allowed  to  reject  universal  integer 
calculations  having  values  that  exceed  SYSTQ1.MAX_INT.  This 
Implementation  processes  64-blt  integer  calculations.  (See  tests 
D4A002A,  D4A002B,  D4A004A,  and  D4A004B.) 


.  Predefined  types . 

This  Implementation  supports  the  additional  predefined  types 
SHORT  INTEGER,  LONG  FLOAT,  and  SHORT  SHORT_INTEGER  in  the  package 
STANDARD.  (See  tests  B86001C  and  B86001D.) 


.  Baised  literals . 

An  Implementation  Is  allowed  to  reject  a  based  literal  with  a 
value  exceeding  SYSTEM. MAX__INT  during  compilation,  or  it  may  raise 
NUMERIC__ERROR  or  C0NSTRAINT__2RR0R  during  execution.  This 
Implementation  raises  NUMERIC_ERROR  durtng  execution.  (See  test 
E24101A.) 


.  Expression  evaluation. 

Apparently  no  default  initialization  expressions  for  record 
components  are  evaluated  before  any  value  is  checked  to  belong  to 
a  component's  subtype.  (See  test  C32117A. ) 

Assignments  for  subtypes  are  performed  with  the  same  precision  as 
the  base  type.  (See  test  C35712B. ) 


2-2 


CONFIGURATION  INFORMATION 


This  implementation  uses  no  extra  bits  for  extra  precision.  This 
implementation  uses  all  extra  bits  for  extra  range.  (See  test 
C35903A.) 

Apparently  NDMERIC__ERROR  is  raised  when  an  Integer  literal  operand 
in  a  comparison  ~or  monbershlp  test  is  outside  the  range  of  the 
base  type.  (See  teat  C45232A.) 

Apparently  NUMERIC^ERROR  is  raised  when  a  literal  operand  in  a 
fixed^point  comparison  or  membership  test  is  outside  the  range  of 
the  base  type.  (See  test  CU5252A.) 

Apparently  underflow  is  not  gradual.  (See  tests  C45524A..Z.) 


Rounding. 

The  method  used  for  rounding  to  integer  is  apparently  round  to 
even.  (See  testa  C46012A..Z.) 

The  method  used  for  rounding  to  longest  integer  is  apparently 
round  to  even.  (See  tests  C46012A..Z.) 

The  method  used  for  rounding  to  Integer  in  static  universal  real 
expressions  is  apparently  round  to  even.  (See  test  C4A014A.) 
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.  Array  types . 

An  Inpleoentation  Is  allowed  to  raise  NUMERIC_ERROR  or 
CONSTRAINT  ERROR  for  an  array  having  a  'LENGTH  that  exceeds 
STANDARD. INTEGER 'LAST  and/or  STSTQ!.MAX_INT.  For  this 
Implementation : 

Declaration  of  an  array  type  or  subtype  declaration  with  more  than 
SYSTEM. MAX  INT  components  raises  NUMERIC  ERROR.  (See  test 
C36003A. )  “ 

NQMERIC_ERROR  is  raised  when  an  array  type  with  INTEGER 'LAST  2 
components  is  declared.  (See  test  C36202A.) 

NtIMERIC_^ERROR  is  raised  when  an  array  type  with  SYSTEM. MAX__INT  +  2 
components  is  declared.  (See  test  C36202B.) 

A  packed  BOOLEAN  airray  having  a  'LENGTH  exceeding  INTEGER 'LAST 
raises  NUMERIC  ERROR  frtien  the  array  type  is  declared.  (See  test 
C52103X.) 

A  packed  two-dimensional  BOOLEAN  array  with  more  tiuui  INTEGER 'LAST 
components  raises  NUMERIC  ERROR  when  the  array  type  is  declared. 
(See  teat  C5210HY.)  “ 

A  null  array  with  one  dimension  of  length  greater  than 
INTEGER 'LAST  may  raise  NUMERIC^ERROR  or  CONSTRAINT_ERROR  either 
when  declared  or  assigned.  Alternatively,  an  implementation  may 
accept  the  declaration.  However,  lengths  must  match  in  array 
slice  assignments.  This  implementation  raises  NUMERIC^ERROR  when 
the  array  type  is  declared.  (See  test  E52103Y.)  ~ 

In  8issigning  one-dlmenslonal  array  types,  the  expression  appears 
to  be  evaluated  in  its  entirety  before  CONSTRAINTJERROR  is  raised 
when  checking  whether  the  expression's  subtype  is  crapatible  with 
the  target's  subtype.  In  assigning  two-dimensional  array  types, 
the  expression  does  not  appear  to  be  evaluated  in  its  entirety 
before  CONSTRAINTJERROR  is  raised  when  checking  whether  the 
expression's  subtype  is  compatible  with  the  target's  subtype. 
(See  test  C52013A.) 


.  Discriminated  types . 

During  compilation,  an  implementation  is  allowed  to  either  accept 
or  reject  an  incomplete  type  with  discriminants  that  is  used  in  an 
access  t^pe  definition  with  a  compatible  discriminant  constraint. 
This  implementation  accepts  such  subtype  indications.  (See  test 
E38104A.) 

In  assigning  record  types  with  discriminants,  the  expression 
appears  to  be  evaluated  in  its  entirety  before  CONSTRAINT_ERROR  is 
raised  when  checking  whether  the  expression's  subtype  is 
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compatible  with  the  target’s  subtype.  (See  test  C52013A.) 


Aggregates . 

In  the  evaluation  of  a  aultl-dlmenslonal  aggregate,  all  choices 
appear  to  be  evaluated  before  checking  against  the  Index  type. 
(See  tests  Ci(3207A  and  C43207B.) 

In  the  evaluation  of  an  aggregate  containing  subaggregates,  not 
all  choices  are  evaluated  before  being  checked  for  identical 
bounds.  (See  test  E43212B. ) 

All  choices  are  evaluated  before  COHSTRAINT^^ERROR  Is  raised  if  a 
bound  In  a  non-null  range  of  a  non-null  aggregate  does  not  belong 
to  an  Index  subtype.  (See  test  E43211B.) 


Representation  clauses. 

For  this  Implementation: 

An  Implementation  might  legitimately  place  restrictions  on 
representation  clauses  used  by  some  of  the  tests*  If  a 
representation  clause  Is  used  by  a  test  In  a  way  that  violates  a 
restriction,  then  the  implementation  must  reject  it. 

Enumeration  representation  clauses  containing  noncontiguous  values 
for  enumeration  types  other  than  character  and  boolean  types  are 
supported.  (See  tests  C35502I. .J,  C35502M..N,  and  A39005F.) 

Enumeration  representation  clauses  containing  noncontiguous  values 
for  character  types  au*e  supported.  (See  tests  C35507I. .J, 
C35507M..N,  and  C55B16a.) 

Enumeration  representation  clauses  for  boolean  types  containing 
representational  values  other  than  (FALSE  =>  0,  TRUE  s>  1)  are 
supported.  (See  tests  C3550dI..J  and  C35508M..N.) 

Length  clauses  with  SIZE  specifications  for  enumeration  types  are 
supported.  (See  test  A39005B. ) 

Length  clauses  with  STORAGE^SIZE  specifications  for  access  types 
are  not  supported.  (See  test  C87B62B.} 

Length  clauses  with  STORAGE__SIZE  specifications  for  task  types  are 
supported.  (See  tests  A39005I>  and  C87B62D.) 

Length  clauses  with  SMALL  specifications  are  supported.  (See 
tests  A39005E  and  C87B62C.) 
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Record  representation  clauses  are  not  supported.  (See  test 
A39005G.) 

Length  clauses  vith  SIZE  specifications  for  derived  integer  types 
are  not  supported.  (See  test  C87B62A.) 


.  Pragmas. 

The  pragsa  INLINE  is  supported  for  procedures.  The  pragsa  INLINE 
is  supported  for  functions,  except  for  the  case  given  in  EA3004D, 
«diere  the  function  is  called  inside  of  a  package  specification. 
(See  teats  USOOKA,  LASOOhB,  EA3004C,  EA3004D,  CA3004E,  and 
CA3004F. ) 


.  Input/output . 

The  package  SEQUENTIAL^IO  can  he  instantiated  with  unconstrained 
array  types  and  record  types  with  discriminants  without  defaults. 
(See  testa  AE2101C,  EE2201D,  and  EE2201E.) 

The  package  DIRECT_IO  cannot  be  instantiated  with  unconstrained 
array  tjrpes  and  record  types  with  discriminants  without  defaults. 
(See  tests  EE2401D  and  EE2401G.) 

There  are  no  strings  which  are  illegal  external  file  names  for 
SEQUENTIAL^IO  and  DIRECT^IO.  (See  tests  CE2102C  and  CE2102H.) 

Modes  IN  FILE  and  OUT  FILE  are  supported  for  SEQUENTIAL  10.  (See 
tests  CE2102D  and  CE2T02E.) 

Modes  IN  FILE,  OUT  FILE,  and  INOUT  FILE  are  supported  for 
DIRECT_Io7  (See  teats  CE2102F,  CE2102I,  and  CE2102J.) 

RESET  and  DELETE  are  supported  for  SEQUENTIAL  10  and  DIRECT  10. 
(See  tests  CE2102G  and  CE2102K.) 

Dynamic  creation  and  deletion  of  files  are  supported  for 
SEQUENTIAL^IO  and  DIRECT^IO.  (See  tests  CE2106A  and  CE2106B.) 

Overwriting  to  a  sequential  file  truncates  the  file  to  last 
element  written.  (See  test  CE2208B.) 

An  existln  text  file  can  be  opened  in  0UT_FILE  mode,  can  be 
created  in  OUT  FILE  mode,  and  can  be  created  in  IN  FILE  mode. 
(See  test  EE3102C.)  ” 

More  than  one  internal  file  can  be  associated  with  each  external 
file  for  text  I/O  for  both  reading  and  writing.  (See  tests 
CE3111A. .E  (5  tests),  CE3114B,  and  CE3115A.) 


2-6 


CONFIGURATION  INFORMATION 


More  than  one  Internal  file  can  be  associated  with  each  external 
file  for  sequential  I/O  for  both  reading  and  writing.  (See  tests 
CE2107A..D  (4  tests),  CE2110B,  and  CE2111D.) 

More  than  one  Internal  file  can  be  associated  with  each  external 
file  for  direct  I/O  for  both  reading  and  writing.  (See  tests 
CE2107F..I  (5  teats),  CE2110B,  and  CE2inH.) 

An  Internal  sequential  access  file  and  an  Internal  direct  access 
file  can  be  associated  with  a  single  external  file  for  writing. 
(See  test  CE2107E.) 

An  external  file  associated  with  oore  than  one  Internal  file  can 
be  deleted  for  SEQUENTIAL  10,  DIRECT  10,  and  TEXT  10.  (See  test 
CE2110B.) 

Temporary  sequential  files  are  given  names.  Temporary  direct 
files  are  given  names.  Temporary  files  given  names  are  deleted 
tdien  they  are  closed.  (See  tests  CE2108A  and  CE2108C.) 


Generics . 

Generic  subprogram  declarations  and  bodies  can  be  compiled  In 

separate  compilations.  (See  tests  CA1012A  and  CA2009F.) 

Generic  package  declarations  and  bodies  can  be  compiled  In 

separate  compilations.  (See  tests  CA2009C,  BC3204C,  and  BC3205D.) 

Generic  unit  bodies  and  their  subunits  can  be  compiled  In  separate 
compilations.  (See  test  CA3011A.) 


CHAPTER  3 
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3.1  test  RESULTS 

Version  1.9  of  the  ACVC  comprises  3122  tests.  When  this  compiler  was 
tested,  27  teats  had  been  withdrawn  because  of  test  errors.  The  AVF 
determined  that  226  tests  were  inapplicable  to  this  implementation.  All 
inapplicable  testa  were  processed  during  validation  testing  except  for  201 
executable  testa  that  use  floating-point  precision  exceeding  that  supported 
by  the  Implementation  .  Modifications  to  the  code,  processing,  or  grading 
for  25  tests  were  required  to  successfully  demonstrate  the  test  objective. 
(See  section  3*6.) 

The  AVF  concludes  that  the  testing  results  demonstrate  acceptable 
conformity  to  the  Ada  Standard. 


3.2  SUMMARY  OF  TEST  RESULTS  BY  CLASS 


RESULT 

A 

B 

TEST  CLASS 
C  D 

E 

L 

TOTAL 

Passed 

109  10H9 

1630 

17 

16 

46 

2867 

Inapplicable 

1 

2 

223 

0 

2 

0 

228 

Withdrawn 

3 

2 

21 

0 

1 

0 

27 

TOTAL 

113  1053  1874 

17 

19 

46 

3122 
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3.3  SUMMARY  OF  TEST  RESULTS  BY  CHAPTER 


RESULT 

2  3 

4 

5 

6 

CHAPTER 

7  8  9 

10 

11  12  13 

14 

TOTAL 

Passed 

190  A99 

540 

245 

166 

98  141  327 

137 

36  234 

3 

251 

2867 

Inapplicable 

14  73 

134 

3 

0 

0  2  0 

0 

0  0 

0 

2 

228 

Withdrawn 

2  14 

3 

0 

0 

1  2  0 

0 

0  2 

1 

2 

27 

TOTAL 

206  586 

677 

248 

166 

99  145  327 

137 

36  236 

4 

255 

3122 

3. A  WITHDRAWN  TESTS 


The 

following  27 

tests  were  withdrawn 

from  ACVC  Version  1.9  at  the  time 

this  validation: 

B28003A 

C35904B 

C37215E 

C45614C 

AD1A01A 

E28005C 

C35A03E 

C37215G 

A74106C 

CE2401H 

C34004A 

C35A03H 

C37215H 

C85018B 

CE3208A 

C35502P 

C37213H 

C38102C 

C87B04B 

A35902C 

C37213J 

C41402A 

CCI31IB 

C35904A 

C37215C 

C45332A 

BC3105A 

See 

Appendix  D  for  the  reason  that  each  of  these 

tests  was  withdrawn. 

3.5  INAPPLICABLE  TESTS 

Some  testa  do  not  apply  to  all  compilers  because  they  make  use  of  features 
that  a  compiler  is  not  required  by  the  Ada  Standard  to  support.  Others  may 
depend  on  the  result  of  another  test  that  is  either  inapplicable  or 
withdrawn.  The  applicability  of  a  test  to  an  implementation  is  considered 
each  time  a  validation  is  attempted.  A  test  that  is  inapplicable  for  one 
validation  attempt  is  not  necessarily  inapplicable  for  a  subsequent 
attempt.  For  this  validation  attempt y  228  tests  were  inapplicable  for  the 
reasons  indicated: 


.  C35702A  uses  SHORT__FLOAT  which  is  not  supported  by  this 

implementation . 

.  A39005G  uses  a  record  representation  clause  which  is  not  supported 

by  this  compiler. 


3-2 


TEST  INFORMATION 


.  The  following  teats  use  LONG_INTEGER,  which  la  not  supported  by 
this  coDpller: 

C45231C  C45304C  C45502C  C45503C  C45504C 

C45504F  C45611C  C45613C  C45631C  C45632C 

B52004D  C55B07A  B55B09C 

.  C45531M,  C45531N,  C45532M,  and  C45532N  use  fine  48-bit  fixed-point 

base  types  which  are  not  supported  by  this  compiler. 

.  C455310,  C45531P,  C455320,  and  C45532P  use  coarse  48-bit  fixed- 

point  base  types  which  are  not  supported  by  this  compiler. 

.  C86001F  redefines  package  STSTEM,  but  TEXTJtO  is  made  obsolete  by 

this  new  definition  in  this  implementation  and  the  test  cannot  be 
executed  since  the  package  REPORT  is  dependent  on  the  package 
TEXT__IO. 

.  C87B62B  uses  length  clauses  with  STORAGE_SIZE  specifications  for 

access  types  which  are  not  supported  by  this  implementation. 

.  EE2401D  and  EE2401G  use  instantiations  of  package  DIRECT_IO  with 

unconstrained  array  types  and  record  types  having  discriminants 
without  defaults.  These  instantiations  are  rejected  by  this 
compiler . 

.  The  following  201  tests  require  a  floating-point  accuracy  that 
exceeds  the  maximum  of  15  digits  supported  by  this  implementation: 

C24113L..Y  (14  tests)  C35705L..I  (14  tests) 

C35706L..y  (14  tests)  C35707L..Y  (14  tests) 

C35708L..Y  (14  tests)  C35802L..Z  (15  tests) 

C45241L..Y  (14  tests)  C45321L..Y  (14  tests) 

C45421L..Y  (14  tests)  C45521L..Z  (15  tests) 

C45524L..Z  (15  tests)  C45621L..Z  (15  tests) 

C45641L..Y  (14  tests)  C46012L..Z  (15  tests) 


3.6  TEST,  PROCESSING,  AND  EVALUATION  MODIFICATIONS 

It  is  expected  that  some  tests  will  require  modifications  of  code, 
processing,  or  evaluation  in  order  to  compensate  for  legitimate 
implementation  behavior.  Modifications  are  made  by  the  AVF  in  cases  vrtiere 
legitimate  Implementation  behavior  prevents  the  successful  conpletion  of  an 
(otherwise)  applicable  test.  Examples  of  such  modifications  Include: 
adding  a  length  clause  to  alter  the  default  size  of  a  collection;  splitting 
a  Class  B  test  into  subtests  so  that  all  errors  acre  detected;  and 
confirming  that  messages  produced  by  an  executable  test  demonstrate 
conforming  behavior  that  wasn't  anticipated  by  the  test  (such  as  raising 
one  exception  instead  of  another). 
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Modlficationa  were  re<]ulred  for  24  Class  B  tests  and  1  Class  E  test. 


The  following  Class  B  tests  were  split  because  syntax  errors  at  one  point 
resulted  in  the  compiler  not  detecting  other  errors  in  the  test: 


B24007A 

B24009A 

B25002A 

B26005A 

B27005A 


B32202A 

B32202B 

B32202C 

B3300U 

B36307A 


B37004A 

B45102A 

B49003A 

B49005A 

B61012A 


B62001B 

B74401F 

B74401R 

B91004A 

B95004A 


B95032A 

B95069A 

B95069B 

BA1101B 


In  test  EA3004Dy  the  pragma  has  no  effect  when  a  function  is  called  inside 
of  a  package  specification;  the  error  at  line  27  in  EA3004D6M.ADA  is  not 
detected.  The  teat  was  recompiled  in  the  following  order:  DO,  D1,  D4,  D5, 
D2,  D3y  and  D6.  The  test  exhibited  the  expected  behavior,  printing 
NOT  APPLICABLE,  and  was  graded  as  passed. 


3.7  ADDITIONAL  TESTING  INFORMATION 
3.7.1  Prevalidation 

Prior  to  validation,  a  set  of  teat  results  for  ACVC  Version  1.9  produced  by 
the  HP  9000  Series  300  Ada  Compiler  was  submitted  to  the  AVF  by  the 
applicant  for  review.  Analysis  of  these  results  demonstrated  that  the 
compiler  successfully  passed  all  applicable  tests ,  and  the  compiler 
exhibited  the  expected  behavior  on  all  inapplicable  tests. 


3.7.2  Test  Method 

Testing  of  the  HP  9000  Series  300  Ada  Compiler  using  ACVC  Version  1.9  was 
conducted  on-site  by  a  validation  team  from  the  AVF.  The  configuration 
consisted  of  a  HP  9000  Series  300  Model  350  host  operating  under  HP -OX, 
Revision  6.01. 

A  magnetic  tape  containing  all  tests  except  for  withdrawn  tests  and  tests 
requiring  unsupported  floating-point  precisions  was  taken  on-site  by  the 
validation  team  for  processing.  Tests  that  make  use  of 
implementation-specific  values  were  customized  before  being  written  to  the 
laagnetic  tape.  Tests  requiring  modifications  during  the  prevalidation 
testing  were  included  in  their  modified  form  on  the  magnetic  tape. 

The  contents  of  the  magnetic  tape  were  loaded  onto  an  HP  Series  9000/320 
computer.  These  files  were  accessed  and  referenced  across  an  Ethernet 
ThinLAN  running  HP's  proprietary  Remote  File  Access  (RFA)  command.  After 
the  test  files  were  loaded  to  disk,  the  full  set  of  tests  was  compiled  and 
linked  on  the  HP  9000  Series  300  Model  350,  and  all  executable  tests  were 
run.  Results  were  sent  via  RFA  to  an  HP  9000/500  Series  computer  acting  as 
a  print  server  on  the  network.  The  print  server  was  used  to  print  all  teat 
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output. 

The  compiler  was  tested  using  command  scripts  provided  by  Hewlett  Packard 
Company  and  reviewed  by  the  validation  team.  The  compiler  was  tested  using 
all  default  option  settings  except  for  the  following: 


Option 

Effect 

Produce  an  output  listing. 

t-P  66" 

Set  the  out  page  length  to  66  lines. 

"_e  999" 

Set  the  maximum  number  of  errors  to  999. 

"-C" 

Compile  and  bind  only.  The  link  phase  is  nm 
separately  under  the  testing  automation,  using 
only  the  default  options. 

For  four  tests  (AE2101A.AOA,  AEaiOIF.ADA,  C35A06N.ADA,  and  CC1221A.ADA)  the 
option  "-u"  was  used.  This  option  places  Information  for  generic 
instantiations  into  a  separate  symbol  table.  If  the  option  were  not  iised, 
the  test  would  have  caused  a  symbol  table  overflow  (compiler  limitation). 
Note  that  all  tests  could  have  been  rtm  with  this  option »  but  doing  so 
would  have  increased  the  overall  time  of  the  compilations. 

Tests  were  compiled,  linked,  and  executed  (as  appropriate)  using  a  single 
host  computer  and  a  single  target  computer.  Test  output,  compilation 
listings,  and  job  logs  were  captured  on  magnetic  tape  and  archived  at  the 
AVF.  The  listings  examined  on-site  by  the  validation  team  were  also 
archived . 


3*7.3  Test  Site 

Testing  was  conducted  at  Hewlett  Packard,  Cupertino,  CA  and  was  completed 
on  04  MAY  88. 
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Hewlett  Packard  Company  has  submitted  the  following 
Declaration  of  Conformance  concerning  the  HP  9000 
Series  300  Ada  Compiler,  Version  3*25. 
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Compiler  Implementen 


Hewlett  Packard  Company 
Computer  Language  Lab 


Ada  Validation  Facility: 

ASD/SCEL 

Wri^-Patterson  Air  Force  Base,  OH 
45433-6503 

Ada  Compiler  Validation  Capability  (ACVC)  Version:  L9 


Base  Configuration 

Base  Compiler  Name:  HP  9000  Series  300  Ada  Compiler,  Version  3  JL5 
Host  and  Target  Architectures: 

Machine:  HP  9000  Series  300  Model  350 
Operating  System:  HP-UX,  Revision  6.01 


Derived  Compiler  Registration 

Derived  Compiler  Name:  HP  9000  Series  300  Ada  CompQer,  Version  325 
Host  and  Target  Architectures: 

Machine:  HP  9000  Series  300  Model  318 
Operating  System;  HP-UX,  Revision  6.01 

Machine:  HP  9000  Series  300  Model  319 
Operating  System:  HP-UX,  Revirion  6.01 

Machine:  HP  9000  Series  300  Model  320 
Operating  System:  HP-UX,  Revision  6.01 

Machine:  HP  9000  Series  300  Model  330 
Operating  System:  HP-UX,  Revision  6.01 

These  four  configurations  are  all  derived  from: 

Machine:  HP  9000  Series  300  Model  350 
Operating  System:  HP-UX,  Revision  6.01 


Implementer's  Declaration 


I,  the  undersigned,  representing  Hewlett  Packard  Company,  have  implemented  no  deliberate  exten¬ 
sions  to  the  Ada  Language  Standard  ANSI/MIL-STD-1815A  in  the  compilers  listed  in  this  declara¬ 
tion.  I  declare  that  Hewlett  Packard  Company  is  the  owner  of  record  of  the  Ada  language  compilers 


listed  above  and,  as  such,  is  responsible  for  maintaining  said  compilers  in  conformance  to 
ANSI/MIL-STD-1815A.  All  certificates  and  registrations  of  Ada  language  compilers  listed  in  this 
declaration  shall  be  made  only  in  the  owner’s  corporate  name. 

Hewlett  Packard  Company 

David  Graham 

Ada  R&D  Section  Manager 


Owner’s  Declaration 

I,  the  undersigned,  representing  Hewlett  Packard  Company,  take  full  responsibility  for  implementa¬ 
tion  and  maintenance  of  the  Ada  compilers  listed  above,  and  agree  to  the  public  disclosure  of  the 
final  Validation  Summary  Report.  I  further  agree  to  continue  to  comply  with  the  Ada  trademark 
poUcy,  as  defined  by  the  Ada  Joint  Program  Office.  I  declare  that  all  of  the  Ada  language  compQers 
listed,  and  their  host/target  performance  are  in  compliance  with  the  Ada  Language  Standard 
ANSI/MIL-STD-1815A. 

5/i/if 

Hewlett  Packard  Company 

David  Graham 

Ada  R&D  Section  Manager 
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APPENDIX  F  OF  THE  Ada  STANDARD 


The  only  allowed  Inplementation  dependencies  correspond  to  implementation- 
dependent  pragmas,  to  certain  machine-dependent  conventions  as  mentioned  in 
chapter  13  of  the  Ada  Standard,  and  to  certain  allowed  restrictions  on 
representation  clauses.  The  implementation-dependent  characteristics  of 
the  HP  9000  Series  300  Ada  Compiler,  Version  3.25,  are  described  in  the 
following  sections,  which  discuss  topics  in  Appendix  F  of  the  Ada  Standard. 
Implementation-specific  portions  of  the  package  STANDARD  are  also  included 
in  this  appendix. 


package  STANDARD  is 


type  INTEGER  is  range  -2  14?  483  648  ..  2  14?  483  647; 
type  SHORT  INTEGER  is  range  ^32  768  ..  32“7677 
type  SH0RT”sH0RT  INTEGER  is  range  -128  ..“l27; 


type  FLOAT  is  digits  6  range  -2#1.ni  1111  1111  1111  111H»E-f.127  .. 

2<H  .  1 1 1J 1 1 1 J 1 1 1 J 1 1 1 J 1 11#E+127; 
type  LONG  FLOAT  is  digits  15  range  -  —  - 

2#1.111  1111  Till  1111  1111  1111  1111  niljlll  1111  1111  1111  1111#E+1023  .. 
2#1 . 1 1 1J 1 1  l"l  1 1  l“l  1 1  l"l  1 1 1J 1 1 1 1  l^l  1  n  J 1 1  ill  1 1 13 1 1  l“l  1 1  l“l  1 1 1#E+1 023 ; 

type  DURATION  is  delta  2#0.000_000_000_000_01#  range  -86_400.0  ..  86J»00.0; 


end  STANDARD; 
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Appendix  F 
Implementation-Dependent 

Characteristics  for  the  HP  9000 

Series  300  Compilation  System 

The  Ada  Programming  Language  is  described  in  the  Reference  Manual  for  the  Ada  Programming 
Language  (LRM).  This  manual.  Appendix  F  of  the  LRM,  lummariies  the  implementation  dependencies  of 
the  HP  Ada  Compilation  System  on  the  HP  9000  Series  300  Computer  System. 

Appendix  F  includes  the  following  information: 

•  HP  implementation 'dependent  pragmas  and  attributes 

•  Specifications  of  the  packages  SYSTEM  and  STANDARD 

•  Restrictions  on  representation  clauses 

•  Restrictions  on  unchecked  type  conversions 

•  Naming  conventions  for  implementation -dependent  coroponentt  in  record  representation  clauses 

•  Implemenution-dependent  characteristics  of  input/output  packages 

•  Information  about  signal  handling,  the  layout  and  alignment  of  daU  types,  and  the  limiu  imposed  by 
the  compiler 

•  Specific  information  about  calling  external  subprograms  written  in  HP  68K  Assembly  Language,  HP  C, 
HP  FORTRAN  77,  and  HP  Pascal,  with  examples. 


Implementation 'Dependent  Characteristics 

( 

F  1.  Implementation-Dependent  Pragmas 

This  section  describes  the  implementation-dependent  aspects  of  pragmas.  A  pragma  is  a  compiler 
directive  that  provides  a  way  to  control  the  behavior  of  one  or  more  components  of  the  Ada  compilation 
system. 

The  pragmas  listed  below  are  described  in  the  sections  which  follow: 

•  Pragmas  used  in  interfacing  with  subprogranu  written  in  other  languages;  pragma  INTERFACE  and 
pragma  INTERFACE^NAME. 

•  Pragmas  used  in  conditional  compilation;  pragma  BEGIN  COMPILE,  pragma  END  COMPILE, 
pragma  NOW^COMPILE,  and  pragma  STOP^COMPILE. 

•  Pragmas  used  to  support  text  processing  toolr.  pragma  INDENT. 

•  Pragmas  that  are  not  implemented. 
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F  1.1  interfacing  the  Ada  Language  with  Other  Languages 

Your  Ada  programs  can  call  subprograms  written  in  other  languages  when  you  use  the  predefined  pragmas 
INTERFACE  and  INTERFACE  NAME.  This  implementation  of  HP  Ada  supports  subprograms  written  in 
HP  68K  Assembly  Language  HP  C,  HP  Pascal,  and  HP  FORTRAN  77  for  HP  9000  Series  300  computers. 
Note  that  compiler  products  from  vendors  other  than  HP  may  not  conform  to  the  parameter  passing 
conventions  given  below.  For  detailed  information,  instructions,  and  examples  for  interfacing  your  Ada 
programs  with  HP  68K  Assembly  Language,  HP  C,  HP  FORTRAN  77,  and  HP  Pascal,  tee  Section  14. 

The  pragma  INTERFACE  (LRAf,  Section  1 3. 9)  informs  the  compiler  that  a  non -Ada  external  subprogram 
unit  will  be  supplied  when  the  Ada  program  is  linked.  Pragma  INTERFACE  specifies  two  things:  the 
programming  language  used  in  the  externsJ  subprogram  and  the  name  of  the  Ada  interfaced  subprogram. 
Implicit  in  the  language  specification  is  the  corresponding  parameter  calling  convention  to  be  used  in  the 
interface. 

The  implementation-defined  pragma  INTERFACE^NAHE  associates  an  alternative  name  with  a  non-Ada 
external  subprogram  that  has  been  specified  to  the  Ada  program  by  the  pragma  INTERFACE  . 

The  two  pragmas  take  the  form: 

pragma  INTERFACE  (  Language jtcune,  Adajsubprogramjiam); 
pragma  INTERFACE_NAME  (  Adajsubprogramjnaim ^  CxternaljKune); 

where: 


Language jfMum  is  one  of  ASSEMBLER,  C,  FORTRAN,  or  PASCAL. 

Adajsubprogramjiame  is  the  name  used  within  the  Ada  program  when  referring  to  the 
*  interfaced  external  subprogram. 

Externaljiaim  is  the  external  name  of  the  subprogram.  This  name  is  literal  and  case 
significant. 


Use  pragma  INTERFACE_^NAME  whenever  the  interfaced  subprogram  name  contains  characters  not 
acceptable  within  Ada  names  or  when  the  interfaced  subprogram  name  must  contain  uppercase  letterfs). 
If  you  omit  pragma  INTERFACE^NAME  the  name  used  is  the  name  of  the  subprogram  specified  in  pragma 
INTERFACE  with  all  alphabetic  characters  in  the  name  shifted  to  lower  case  and  then  truncated  to  255 
characters  if  necessary.  If  the  interfaced  subprogram  language  is  HP  C,  HP  Pascal  or  HP  FORTRAN  77, 

the  compiler  modifies  the  name  further  the  name  is  prefixed  with  one  underscore  character  ( _ )  and  then 

truncated  to  255  characters  if  necessary.  This  modification  conforms  to  the  naming  conventions  used  by 
the  HP  linker  (Link  Editor)  on  HP-UX  systema 

Pragma  INTERFACE_NAME  is  allowed  at  the  same  places  in  an  Ada  program  as  pragma  INTERFACE  ( see 
LRM  Section  13.9)7  Pragma  INTERFACE_NAM£  must  follow  the  declaration  of  the  corresponding 
pragma  INTERFACE  and  must  be  within  the  same  declarative  part,  though  it  need  not  immediately  follow 
that  declaration.  The  following  example  illustrates  the  use  of  these  j  ragmas. 
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EXAMPLE: 


packag*  SAMPLE__LIB  ia 

function  SAMPLE  DEVICE  (X  :  INTEGER)  roturn  INTEGER; 
function  PROCESS_SAMPLE  (X  :  INTEGER)  roturn  INTEGER; 

private 

pragma  INTERFACE  (ASSEMBLER*  SAMPLE  DEVICE  ); 
pragma  INTERFACE  (C.  PROCESS^SAMPLE") ; 

pragma  INTERFACE  NAME  (SAMPLE  DEVICE*  "DovIO"  ); 
pragma  INTERFACE'naME  (PR0CESS_SAMPLE*  "DOsampla"  ); 

and  SAMPLE_LIB  ; 

Notice  that  the  external  names  of  the  interfaced  function  subprograms  SAMPLE_DEVICE  and 
PROCESS_SAMPLE  contain  uppercase  letters.  These  external  subroutine  names  differ  from  the  names  used 
within  the  Ada  calling  program. 

To  avoid  conflicts  with  the  Ada  run-time  system,  the  names  of  interfaced  external  subprograms  should 
not  begin  with  the  letters  "RTS."  or  “ALSY"  in  any  combination  of  uppercase  and  lowercase. 

To  avoid  conflicts  with  the  HP-UX  operating  system  or  the  standard  HP-UX  library  of  supported 
subroutines,  the  names  of  interfaced  subprograms  should  not  be  the  same  as  the  name  of  any  operating 
system  system  call  (see  Section  2  of  the  HP-UX  Reference)  or  the  name  of  any  HP-supplied  subroutine 
library  routine  (see  Section  3  of  the  HP-UX  Reference).  When  you  want  to  call  one  of  these  HP-UX 
library  or  system  routines,  direct  the  binder  and  linker  to  utilke  code  from  the  system  or  subroutine 
library. 

For  detailed  information  on  the  use  of  pragma  INTERFACE  and  pragma  !NTERFACE_NAME,  see 
Section  F  1 4. 
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F  1.2  Pragma  INDENT 

Pragma  INDENT  is  ignored  by  the  compiler,  bat  it  is  reserved  for  support  of  future  Ada  source  text 
processing  tools. 

The  following  are  reserved  for  use  with  a  source  text  reformatting  tool  (often  referred  to  as  an  Ada  pretty 
printer). 

The  pragmas  INOENT(ON)  and  INDENT  (OFF)  affect  only  the  HP  supplied  reformatter.  You  can  place 
these  pragmas  in  the  source  code  to  control  the  actions  of  the  reformatter.  Table  F- 1  lisu  the  use  of  each 
pragma. 


Table  F-1.  Pragma  Indent 


Pragma 

Description 

IN DENT (OFF) 

The  reformatter  does  not  modify  the  source  lines  after  the  pragma. 

INOENT(ON) 

The  reformatter  resumes  its  action  after  the  pragma. 

F  1.3  Pragmas  Not  Imptementod 

The  following  pragmas  are  not  implemented  and  aoll  imue  a  warning  at  compile  time: 

CONTROLLED 
MEMORY  SIZE 
OPTIMIZE 
PACK 
SHARED 
STORAGE  UNIT 
SYSTEM  NAME 


Note  that  PACKing  of  record  types  is  done  systematically  by  the  HP  Ada  compiler,  but  there  is  no 
PACKing  done  for  array  typea 
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F  2.  Implementation-Dependent  Attributes 

In  addition  to  the  representation  attributes  discussed  in  the  LRM,  Sections  1 3. 7. 2  and  1 3. 7. 3,  there  are 
four  implementation -defined  attributes: 

'RECORD  SIZE 
'VARIANT  INDEX 
'ARRAY  DESCRIPTOR 
'RECORD_DESCRIPTOR 

The  attributes  listed  above  are  discussed  in  Section  F  5 ,  "Conventions  for  Implementation -Generated 
Names”  because  the  attributes  exist  for  use  in  record  representation  clausea 

Note  also  that  there  are  limitations  on  the  use  of  the  'ADDRESS  attribute.  The  attribute  'ADDRESS  is 
implemented  for  all  prefixes  that  have  meaningful  addresses.  However,  the  following  entities  do  not  have 
meaningful  addresses  and  will  cause  a  compilation  error  if  used  as  a  prefix  to  'ADDRESS: 

•  A  constant  that  is  implemented  as  an  immediate  value  (that  is,  the  constant  does  not  have  space 
allocated  for  it). 

•  A  package  specification  that  is  not  a  library  unit. 

•  A  package  body  that  is  not  a  library  unit  or  subunit 

On  the  HP  9000  Series  300  implementation,  the  use  of  'ADDRESS  on  the  following  units  returns  a  value 
that  has  no  meaningful  interpretation: 

•  a  procedure  specification  • 

•  a  procedure  My 

•  a  function  specification 

•  a  function  body 

If  you  use  'ADDRESS  on  a  program  unit,  the  compiler  issues  a  warning  at  compile  time. 
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F  3.  The  SYSTEM  and  STANDARD  Packages 

This  section  contains  a  complete  listing  of  the  two  predefined  library  packages:  SYSTEM  and  STANDARD. 
These  packages  both  contain  implementation -dependent  specificationa 

F  3.1  The  Package  SYSTEM 

The  specification  of  the  predefined  library  package  SYSTEM  followr 

package  SYSTEM  it 

--  Standard  Ada  deflnitlont 

type  NAME  it  (  HP9000  300  ); 

SYSTEM_NAME:  constant  NAME  :«  HP9000_300; 

ST0RACE_UNIT:  constant  :•  6; 

M£MORY_SI2E;  constant  ;■  (2**31)-1; 

MIN_INT;  constant  :*  -(2*«31); 

MAX^INT:  constant  :*  2**31-1; 

MAX^DICITS:  constant  :«  tSj  • 

MAX^MANTISSA;  constant  :•  31; 

FINE_OELTA:  constant  :■  2#1.0#e-31; 

TICK:  constant  :■  0.020;  20  milllsaconds 

subtype  PRIORITY  Is  INTEGER  range  1..12T  ; 

type  ADDRESS  is  private; 

NULL_ADORESS  :  constant  ADDRESS;  —set  to  NULL 
--  Address  arithmetic 

function  TOJNTECER  (LEFT  :  ADDRESS)  return  INTEGER; 

function  T0_ADDRESS  (LEFT  :  INTEGER)  return  ADDRESS; 

—  Note  that  ADDRESS  ADDRESS  is  not  supported 

function  (LEFT  ;  INTEGER;  RIGHT  :  ADDRESS)  return  ADDRESS; 

function  (left  :  ADDRESS;  RIGHT  :  INTEGER)  return  ADDRESS; 

--  Note  thst  INTEGER  -  ADDRESS  is  not  supported 

function  (LEFT  :  ADDRESS;  RIGHT  :  ADDRESS)  return  INTEGER; 

function  (LEFT  :  ADDRESS;  RIGHT  :  INTEGER)  return  ADDRESS; 
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function 

(LEFT  : 

ADDRESS; 

RIGHT  : 

ADDRESS) 

return 

BOOLEAN; 

function 

(LEFT  : 

ADDRESS; 

RIGHT  ; 

ADDRESS) 

return 

BOOLEAN; 

function 

H  ^SS 

(LEFT  : 

ADDRESS; 

RIGHT  ; 

ADDRESS) 

return 

BOOLEAN; 

function 

(LEFT  : 

ADDRESS; 

RIGHT  : 

ADDRESS) 

return 

BOOLEAN ; 

function 

"mod** 

(LEFT  : 

ADDRESS; 

RIGHT  : 

POSITIVE) 

return 

NATURAL; 

function  IS_NULL  (LEFT  ;  ADDRESS)  rotum  BOOLEAN; 


function  WORD_ALICNED  (LEFT  :  ADDRESS)  return  BOOLEAN; 

function  ROUND  (LEFT  ;  ADDRESS)  rotum  ADDRESS; 

return  the  given  addreee  rounded  to  the  next  lower  even  value 

procedure  COPY  (FROM  :  ADDRESS;  TO  ;  ADDRESS;  SIZE  :  NATURAL); 

— •  copy  SIZE  storage  units.  The  result  is  undefined  if 

—  the  two  storage  areas  overlap. 

--  functions  to  provide  some  READ/WRITE  operations  in  memory, 
generic 

type  ELEMENT  TYPE  is  private; 
function  FETCH  TfROM  :  ADDRESS)  return  ELEMENT__TYPE; 

--  Return  the  bit  pattern  stored  at  address  FROM,  as  a  value  of 
*-  specified  ELEMENT__TYPE.  This  function  is  NOT  implemented  for 

—  unconstrained  array  types. 

generic 

type  ELEMENT  TYPE  is  private; 
procedure  ST0RE"(INT0  :  ADDRESS;  OBJECT  :  ELEMENTJTPE); 

—  Store  the  bit  pattern  representing  the  value  of  OBJECT, at 
address  INTO.  This  function  is  NOT  implemented  for 

--  unconstrained  array  types. 

private 

—  private  part  of  package  SYSTEM 


end  SYSTEM; 
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F  3.2  The  Package  STANDARD 

The  specification  of  the  predefined  library  package  STANDARD  follows: 


paickag*  STANDARD  it 

—  Th*  oparators  that  ara  pradafinad  for  tha  typae  daelarad  in  thia 
--  packaga  ara  givan  in  eommants  tinea  thay  ara  implicitly  daelarad. 
*■*  Lowar  cata  it  utad  for  ptaudo-namat  of  anonymous  typat  (tuch  as 
--  univartal^raal,  univartal_intagar,  and  univartal_f ixad)  and  for 
»  undafinad  information  (such  at  any  fixad  point  typa). 


—  Pradafinad  typa  BOOLEAN 

>■*  Harning:  intarnal  rapratantation  of  BOOLEAN  it  NOT  simply  0*1 
typa  BOOLEAN  it  (FALSE.  TRUE); 

Tha  pradafinad  ralation  oparators  for  this  typa  ara  at  follows 


>■*  (thasa  ara  implicitly  daelarad): 


—  function 

(LEFT. 

RIGHT 

BOOLEAN) 

return 

BOOLEAN; 

—  function 

(LEFT. 

RIGHT 

BOOLEAN) 

return 

BOOLEAN; 

--  function 

(LEFT. 

RIGHT 

BOOLEAN) 

return 

BOOLEAN; 

—  function 

(left. 

RIGHT 

BOOLEAN) 

return 

BOOLEAN; 

—  function 

^  M 

(LEFT, 

RIGHT 

BOOLEAN) 

return 

BOOLEAN; 

--  function 

(LEFT, 

RIGHT 

BOOLEAN) 

return 

BOOLEAN; 

Tha  pradafinad  logical  oparandt  and  tha  pradafinad  logical 
negation  operator  ara  as  follows  (these  ara  implicitly 
—  declared): 


-  function  "and"  (LEFT,  RIGHT  :  BOOLEAN)  return  BOOLEAN; 

-  function  "or"  (LEFT,  RIGHT  :  BOOLEAN)  return  BOOLEAN; 

-  function  "xor"  (LEFT,  RIGHT  :  BOOLEAN)  return  BOOLEAN; 


—  function  "not"  (RIGHT  :  BOOLEAN)  return  BOOLEAN; 


--  Predefined  universal  types 


*-  typa  univartal_intagar  it  pradafinad; 

--  Tha  pradafinad  operators  for  tha  typa  univarsaWntagar  ara  as  follows 
(theta  ara  implicitly  declared): 

function  (LEFT,  RIGHT  ;  universe l__intagar)  return  BOOLEAN; 

--  function  "/■"  (LEFT,  RIGHT  :  univarsal_intagar)  return  BOOLEAN; 

--  function  "<"  (LEFT,  RIGHT  ;  univarsal^intagar)  return  BOOLEAN; 

--  function  "<«"  (LEFT,  RIGHT  :  univarsal_intagar)  return  BOOLEAN; 

--  function  ">"  (LEFT,  RIGHT  ;  univarsal__intagar)  return  BOOLEAN; 

--  function  ">■"  (LEFT,  RIGHT  :  universal  intagar)  return  BOOLEAN; 
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--  function 

(RIGHT 

--  function 

IS  IS 

(RIGHT 

—  function 

"aba" 

(RIGHT 

--  function 

(left. 

--  function 

SS  SI 

(LEFT, 

--  function 

(LEFT, 

--  function 

ts 

(LEFT, 

--  function 

”  r#m** 

(LEFT, 

--  function 

"mod" 

(LEFT, 

—  function 

(LEFT 

»ek 

RIGHT 

univ*r«al_int«g«r)  raturn  univ«rsal_int«g«r; 
unlv«r8»l_lnt«g«r)  return  univ«rsal_int*g«r; 
univ*rMl_lnt*ger)  return  universal_integer; 


RIGHT  : 
RIGHT  : 
RIGHT  ; 
RIGHT  ; 
RIGHT  : 
RIGHT  : 


universal 

universal 

universal 

universal 

universal 

univeraal 


integer) 

integer) 

integer) 

integer) 

_lnteger) 

^integer) 


return 

return 

return 

return 

return 

return 


universal^ 

universal 

universal 

universal 

universal 

universal 


integer 

integer 

integer 

integer 

integer 

integer 


univeraal^integer; 

INTEGER)  return  universal^integer; 


■»  type  universal  real  is  predefined: 


The  predefined  operators  for  the  type  universal^real  are  as  follows 
(these  are  implicitly  declared): 


function 
funct ion 
function 
function 
function 
function 


(LEFT,  RIGHT 
7-*’  (LEFT,  RIGHT 
•<"  (LEFT,  RIGHT 
•<«*•  (LEFT,  RIGHT 
*>•'  (LEFT,  RIGHT 
(LEFT,  RIGHT 


universe l_real) 
univeraal^real) 
universe l”real) 
univeraa Israel) 


return  BOOLEAN; 
return  BOOLEAN; 
return  BOOLEAN; 
return  BOOLEAN; 


universal_real)  return  BOOLEAN; 
universal_real)  return  BOOLEAN; 


—  function  (RIGHT  :  universal^real)  return  universal_real; 

—  function  (RIGHT  :  universal~real)  return  universal”real; 

—  function  "aba"  (RIGHT  :  universal^real)  return  universal”real; 


—  function  ..  (LEFT,  RIGHT  :  unlversal^real)  return  universsl^real; 
■—  function  ( LEFT Wight,  :  universal^real)  return  universal,_^real; 
--  function  (LEFT,  RIGHT  :  universe l_real)  return  universal_real; 
--  function  ”/"  (LEFT,  RIGHT  :  universal  real)  return  univeraal  real; 


—  function  (LEFT  :  universal_real; 

—  RIGHT  ;  INTECER)”return  universal  real; 


—  In  addition,  the  following  operators  are  predefined  for  universal  types: 


—  function 

—  function 

--  function  "/" 


(LEFT  :  universal__integer; 

RIGHT  :  universal^real)  return  universal__real; 
(LEFT  :  universal^real; 

RIGHT  :  universal^integer)  return  universal^real; 
(LEFT  :  universal^real; 

RIGHT  :  universal'^integer)  return  universal_real; 


--  type  un i versa l_fixed  is  predefined; 

—  The  only  operators  declared  for  this  type  are: 

—  function  (LEFT  :  any_f ixed^polnt_type; 

--  RIGHT  ;  any  f  ixed_point_^type)  return  uni  versa  Infixed; 
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--  function  "/”  (LEFT  ;  any_f ix«d_point_typo; 

—  RIGHT  ;  any  fixed  point  typo)  poturn  universal  fixed; 


—  Predefined  and  additional  integer  types 


type  SHORT_SHORT_INTECER  is  range  -128  .. 
--  this  is  equivalent  to  -(2**7)  ..  (2**7  - 
--  The  predefined  operators  for  this  type  a 
--  (these  are  implicitly  declared): 


function 

function 

function 

function 

function 

function 


•7* 

”<» 
M  ^11 

">* 


(LEFT,  RIGHT 
(LEFT.  RIGHT 


(LEFT, 

(LEFT. 

(LEFT. 

(LEFT, 


RIGHT 

RIGHT 

RIGHT 

RIGHT 


127;  --  6  bits  long 

1) 

re  as  follows 

SHORT  SHORT  INTEGER)  return  BOOLEAN 
SH0RT“SH0RT”INTE0ER)  return  BOOLEAN 
SHORT'sHORT'INTEGER)  return  BOOLEAN 
short"* SH0RT”INTE0ER)  return  BOOLEAN 
SHORT'shORT^INTEGER)  return  BOOLEAN 
SHORT'“sHORT”INTEOER)  return  BOOLEAN 


function  *'♦"  (RIGHT  :  SHORT  SHORT  INTEGER)  return  SHORT  SHORT  INTEGER; 
function  (RIGHT  :  SHORT'shORT" INTEGER)  return  SHORT’SHORT-INTECER; 
function  “abs**  (RIGHT  :  SHORT"shORT"INTEGER)  return  SH0RT"SH0RT"”INTEGER; 


—  function 

—  function 

—  function 

ea  m 

—  function  *7" 

—  function  "pen*’ 

m  m 

—  function  "mod" 


(LEFT.  RIGHT  :  SHORT  SHORT  INTEGER) 
return  SHORT  SHORT  INTEGER; 

(LEFT,  RIGHT  T  SHORT  SHORT  INTEGER) 
return  SHORT  SHORT  INTEGER; 

(LEFT,  RIGHT  T  SHORT  SHORT  INTEGER) 
return  SHORT  SHORT  INTEGER; 

(LEFT,  RIGHT  7  SHORT  SHORT  INTEGER) 
return  SHORT  SHORT  INTEGER;  * 

(LEFT.  RIGHT  T  SHORT  SHORT  INTEGER) 
return  SHORT  SHORT  INTEGER; 

(LEFT,  RIGHT  T  SHORT  SHORT  INTEGER) 
return  SHORT  SHORT  INTEGER; 


function  (LEFT  ;  SHORT  SHORT  INTEGER; 

RIGHT  :  INTEGER)  return  SHORT  SHORT  INTEGER; 


type  SHORT  INTEGER  it  range-32_768  ..  32_7S7;  —16  bite  long 


-  this  is  equivalent  to  -(2**15)  ..  (2**15  -1) 


--  The  predefined  operators  for  this  type  are  as  follows 
--  (these  are  implicitly  declared): 


--  function 

(LEFT, 

RIGHT 

--  function 

••/m" 

(left. 

RIGHT 

—  function 

n  ^  ai 

(LEFT, 

RIGHT 

--  function 

(LEFT, 

RIGHT 

—  function 

•  •  ^  H 

(LEFT, 

RIGHT 

--  function 

(LEFT, 

RICHT 

SHORT  INTEGER)  return  BOOLEAN; 
SHORT”inTECER)  return  BOOLEAN; 
SHORT”inTEGER)  return  BOOLEAN; 
SHORT'INTEGER)  return  BOOLEAN; 
SH0RT"INTEGER)  return  BOOLEAN; 
SHORT'iNTEGER)  return  BOOLEAN; 


-  function  (RIGHT  :  SHORT  INTEGER)  return  SHORT  INTEGER; 

-  function  (RIGHT  ;  SHORT-INTEGER)  return  SHORT-INTEGER; 

-  function  "aba"  (RIGHT  :  SHORT-INTEGER)  return  SHORT-INTEGER; 
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—  function  (LEFT,  RIGHT  :  SHORT  INTEGER)  roturn  SHORT  INTEGER 

—  function  *•-"  (LEFT,  RIGHT  :  SHORT^INTEGER)  roturn  SH0RT”INTEGER 

—  function  ”•'*  (LEFT,  RIGHT  :  SHORT”inTEGER)  roturn  SHORT"inTEGER 

—  function  *7“  (LEFT,  RIGHT  :  SHORT"inTEGER)  roturn  SHORf-INTEGER 

—  function  “r«m"  (LEFT,  RIGHT  :  SHORT"inTEGER)  roturn  SHORT"inTEGER 

—  function  "mod"  (LEFT,  RIGHT  ;  SH0RT"INTEGER)  roturn  SHORT^NTEGER 

—  function  "**"  (LEFT  ;  SHORT  INTEGER; 

RIGHT  ;  INTEGER)  rmturn  SHORT  INTEGER; 


typo  INTEGER 


i«  rongo  -2_147_483jB48 


2J47_,483_647;  --32  bit*  long 


this  is  oquivalont  to  -(2**3i)  ..  (2**31  -1) 

Th*  prodofinod  oporators  for  this  typo  aro  as  follows 
(thoso  aro  implicitly  doelarod): 


function 

function 

function 

function 

function 

function 


•7* 

"<• 


(LEFT,  RIGHT 
(LEFT,  RIGHT 
(LEFT,  RIGHT 
(LEFT.  RIGHT 
(LEFT.  RIGHT 
(LEFT.  RIGHT 


INTEGER) 

INTEGER) 

INTEGER) 

INTEGER) 

INTEGER) 

INTEGER) 


rot urn  BOOLEAN; 
roturn  BOOLEAN; 
rotum  BOOLEAN; 
roturn  BOOLEAN; 
roturn  BOOLEAN; 
roturn  BOOLEAN; 


—  function  (RIGHT  ; 

—  function  (RIGHT  s 

—  function  "aba"  (RIGHT  ; 


INTEGER)  roturn  INTEGER; 
INTEGER)  roturn  INTEGER; 
INTEGER)  roturn  INTEGER; 


function 
function 
function  **•** 
function  **/** 
function  "rom 
function  "mod 


(LEFT.  RIGHT 
(LEFT.  RIGHT 
(LEFT.  RIGHT 
(LEFT.  RIGHT 
(LEFT,  RIGHT 
(LEFT.  RIGHT 


INTEGER)  rotum  INTEGER; 
INTEGER)  rotunr  INTEGER; 
INTEGER)  rotum  INTEGER; 
INTEGER)  rotum  INTEGER; 
INTEGER)  roturn  INTEGER; 
INTEGER)  rotum  INTEGER; 


-  function  (LEFT  :  INTEGER;  RIGHT  ;  INTEGER)  rotum  INTEGER; 


--  Prodofinod  INTEGER  subtypos 

subtypo  NATURAL  is  INTEGER  rsngo  0  ..  INTEGER'LAST; 
subtypo  POSITIVE  is  INTEGER  rango  1  ..  INTEGER'LAST; 


—  Prodofinod  and  additional  floating  point  typos 

typo  FLOAT  is  digits  6  rango  —  32  bits  long 
-2#1.ni  1111  1111  1111  1111  1111#E+127  .. 

2#1 . 1 1  l"l  1 1  l"l  1 1 1 J  1 1 1J 1 1 1 J 1 1 1#E+127; 

—  This  is  oquivalont  to  -(2.0  -  2.0»*(-23))  *  2.0«ol27  .. 

♦(2.0  -  2.0*o(-23))  *  2.0**127 

--  This  is  approximatoly  oqual  to  tho  docimal  rango: 

—  -3.402823E+38  ..  +3 . 402823E+38 
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Th*  predefined  operatore  for  this  type  are  aa  followa 
(these  are  implicitly  declared): 


function  • 
function  *'/■’ 
function  “<’* 


function 

function 

function 


(LEFT,  RIGHT 
(LEFT,  RIGHT 
(LEFT,  RIGHT 
(LEFT,  RIGHT 
(LEFT,  RIGHT 
(LEFT,  RIGHT 


FLOAT)  return 
FLOAT)  return 
FLOAT)  return 
FLOAT)  return 
FLOAT)  return 
FLOAT)  return 


BOOLEAN ; 
BOOLEAN; 
BOOLEAN ; 
BOOLEAN; 
BOOLEAN ; 
BOOLEAN ; 


—  function  (RIGHT  :  FLOAT)  return  FLOAT; 

—  function  (RIGHT  ;  FLOAT)  return  FLOAT; 

—  function  "aba"  (RIGHT  :  FLOAT)  return  FLOAT; 

—  function  (LEFT,  RIGHT  ;  FLOAT)  return  FLOAT; 

—  function  (LEFT,  RIGHT  :  FLOAT)  return  FLOAT; 

—  function  (LEFT,  RIGHT  :  FLOAT)  return  FLOAT; 

—  function  "f"  (LEFT,  RIGHT  :  FLOAT)  return  FLOAT; 

—  function  (LEFT  :  FLOAT;  RIGHT  :  INTEGER)  return  FLOAT; 


type  LONG  FLOAT  is  digits  IS  range  »  64  bits  long 

-2#  1 . 11 1 1 J 1 1 1J 1 1 1 J 1 1 1 J 1 1 1J  1 1 1 J 1 1 1 J 1 1 1 J 1 1 1 J 1 1 1 J  1 1 1 J  1 1 1_1 1 11  #E+1 023 
2#  1 . 1 1 1 1 J 1 1 1 J 1 1 1 J 1 1 1 J  1 1 1 J  1 1 1_1 1 1 1 J 1 1 1 J 1 1 1 J 1 1 1 J  1 1 1_1 1 1 1 J 1 1 1IE+1 023 ; 

—  This  is  equivalent  to  -(2.0  -  2.0*«(-52))  *  2.0**1023  .. 

♦(2.0  -  2.0**(-52))  •  2.0»*1023  .. 

—  This  is  approximately  equal  to  the  decimal  range: 

—  - 1.7976931 348623 15E^308  ..  ♦! .79769313486231 5E^308 


-  The  predefined  operators  for  this  type  are  as  follows 

-  (these  are  implicitly  declared): 


—  function 

(LEFT, 

RIGHT 

—  function 

•y." 

(LEFT, 

RIGHT 

—  function 

H  ^  M 

(LEFT, 

RIGHT 

—  function 

H<^M 

(LEFT, 

RIGHT 

—  function 

•f 

(LEFT, 

RIGHT 

—  function 

’•>«" 

(LEFT, 

RIGHT 

LONG  FLOAT)  return  BOOLEAN; 
LONG'fLOAT)  return  BOOLEAN; 
L0MG"FL0AT)  return  BOOLEAN; 
L0NG”fL0AT)  return  BOOLEAN; 
LONG'fLOAT)  return  BOOLEAN; 
L0NC”fL0AT)  return  BOOLEAN; 


—  function  "♦"  (RIGHT  :  LONG  FLOAT)  return  LONG  FLOAT; 

—  function  (RIGHT  ;  LONC“*FLOAT)  return  L0NG”FL0AT; 

—  function  "abs"  (RIGHT  :  LONC~FLOAT)  return  L0NG"FL0AT; 

--  function  "♦"  (LEFT,  RIGHT  :  LONG  FLOAT)  return  LONG  FLOAT; 

—  function  (LEFT,  RIGHT  :  LONG'flOAT)  return  L0NG”FL0AT; 

—  function  (LEFT,  RIGHT  ;  LONG^FLOAT)  return  L0NG”fL0AT; 

—  function  *7"  (LEFT,  RIGHT  :  L0NG”fL0AT)  return  L0NG”FL0AT; 

—  function  (LEFT  :  LONG  FLOAT;  RIGHT  :  INTEGER)  return  L0NG_FL0AT; 


--This  implementation  does  not  provide  any  other  floating  point  types 
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--  Pr«d«fin*d  typ«  DURATION 

typ*  DURATION  is  delta  2#0.000_000_000_000_01#  range  -86_400.0  ..  86^400. 0 

—  DURATION 'SMALL  derived  from  this  delta  is  2.0**(-14)  ,  which  is  the 
--  maximum  precision  that  an  object  of  type  DURATION  can  have  and  still 
--  be  representable  in  this  implementation.  This  has  an  approximate 

—  decimal  equivalent  of  0.000061  (61  microseconds). 

--  The  predefined  operators  for  the  type  DURATION  are  the  same  as  for  any 
--  fixed  point  type. 

—  This  implementation  provides  many  anonymous  predefined  fixed  point 

—  types.  They  consist  of  all  types  whose  "small”  value  ia 

--  any  power  of  2.0  between  2.0  (-31)  and  2.0  (31 )» 

--  and  whose  mantissa  can  be  expressed  using  31  or  less  binary  digits. 

--  The  following  lists  characters  for  the  standard  ASCII  character  set. 

--  Character  literals  corresponding  to  control  characters  are  not 

—  identifiers;  they  are  indicated  in  lower  case  in  this  section. 


—  Predefined  type  CHARACTER 
type  CHARACTER  is 


nul. 

soh. 

stx. 

etx. 

eot. 

enq. 

ack. 

bel. 

bs. 

ht. 

If. 

vt. 

ff. 

cr. 

so. 

si. 

die. 

del. 

dc2. 

dc3, 

dc4. 

nak. 

syn. 

etb. 

can. 

em. 

sub. 

esc. 

fs. 

ga. 

rs. 

us. 

0  0 

• 

'r. 

0%%  0 

% 

'$'. 

'A'. 

0  0  0 

9 

')\ 

0  0 

9  9 

0  0 
*  9 

0  0 

♦  % 

'O', 

'r. 

'2'. 

'3'. 

'4'. 

'5'. 

'6'. 

'7'. 

'8'. 

'9', 

•  9 

”  ♦  ^ 

9  9 

'A'. 

'B'. 

'C', 

'O'. 

'E'. 

'F'. 

'O'. 

'H', 

'I', 

'J*. 

'K', 

'L'. 

'M'. 

'N'. 

'O'. 

'P', 

'O'. 

'R'. 

'S'. 

'T'. 

'U'. 

'V'. 

'W'. 

'X', 

'Y', 

'Z', 

'I'. 

'1'. 

0  0^9 

• 

0  0 
^  9 

0  0 

% 

's'. 

'b'. 

'e'. 

'd'. 

f'. 

'g'. 

'h'. 

'i'. 

'r. 

'k'. 

'1'. 

'n'. 

'o'. 

'p'. 

'r'. 

'r'. 

's'. 

't'. 

'u'. 

'v'. 

'«'» 

'x'» 

0  0 
y  » 

'2'. 

'('. 

'1'. 

0  m  0 

9 

DEL) 

— The  predefined  operators  for  the  type  CHARACTER  are  the  same  as 
— for  any  enumeration  type. 


—  Predefined  type  STRING  (RM  3.6.3) 

type  STRING  is  array  (POSITIVE  range  <>)  of  CHARACTER; 

—  The  predefined  operators  for  this  type  are  as  follows: 

—  function  (LEFT,  RIGHT  ;  STRING)  return  BOOLEAN; 

—  function  "/«"  (LEFT,  RIGHT  :  STRING)  return  BOOLEAN; 

--  function  *'<"  (LEFT,  RIGHT  ;  STRING)  return  BOOLEAN; 

--  function  "<«"  (LEFT,  RIGHT  :  STRING)  return  BOOLEAN; 
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—  function  ">"  (LEFT,  RIGHT  :  STRING)  return  BOOLEAN; 

—  function  ">»"  (LEFT,  RIGHT  ;  STRING)  return  BOOLEAN; 

—  Predefined  catenation  operatora 

—  function  "Ii"  (LEFT  :  STRING;  RIGHT  :  STRING)  return  STRING; 

—  function  "k"  (LEFT  :  CHARACTER;  RIGHT  :  STRING)  return  STRING; 

—  function  "fc”  (LEFT  :  STRING;  RIGHT  :  CHARACTER)  return  STRING; 

—  function  "k"  (LEFT  ;  CHARACTER;  RIGHT  ;  CHARACTER)  return  STRING; 


—  Predefined  except iona 
CONSTRAINT_ERROR  :  exception; 

NUMERIC__ERROR  :  exception; 

PROGRAM_ERROR  :  exception; 

STORAGE_ERROR  :  exception; 

TASKING  ERROR  :  exception; 


—  Predefined  package  ASCII 
package  ASCII  ia 

--  Control  charactera 
NUL  :  constant  CHARACTER  :•  nul; 

SOH  :  conatent  CHARACTER  :■  aoh; 

STX  ;  constant  CHARACTER  5"  atx; 

ETX  ;  constant  CHARACTER  ;»  etx; 

EOT  :  constant  CHARACTER  :•  eot; 

ENQ  :  constant  CHARACTER  :«  enq; 

ACK  :  conatant  CHARACTER  :«  aek; 

BEL  :  constant  CHARACTER  :■  bel; 

BS  :  constant  CHARACTER  :«  bs; 

HT  ;  constant  CHARACTER  :»  ht; 

LF  :  constant  CHARACTER  :«  If; 

VT  ;  constant  CHARACTER  ;■  vt; 

FF  :  constant  CHARACTER  ;■  ff; 

CR  :  constant  CHARACTER  :■  cr; 

50  ;  constant  CHARACTER  :«  so; 

51  :  constant  CHARACTER  :■  si; 

OLE  :  constant  CHARACTER  ;»  die; 

DC1  ;  constant  CHARACTER  ;•  del; 

DC2  ;  constant  CHARACTER  :■  dc2; 

0C3  ;  constant  CHARACTER  :■  dc3; 

DC4  ;  constant  CHARACTER  :■  dc4; 

NAK  :  constant  CHARACTER  :■  nak; 

SYN  :  constant  CHARACTER  :■  syn; 

ETB  :  constant  CHARACTER  ;*  etb; 

CAN  :  constant  CHARACTER  ;■  can; 

EM  :  conatant  CHARACTER  :■  em; 

SUB  :  constant  CHARACTER  :«  sub; 

ESC  ;  constant  CHARACTER  :■  esc; 

FS  :  constant  CHARACTER  :*  fs; 

CS  :  constant  CHARACTER  ;■  gs; 

RS  :  constant  CHARACTER  :■  rs; 
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US  :  constant  CHARACTER  :«  us; 
DEL  :  constant  CHARACTER  :■  dal; 


--  other  characters 


EXCLAM 

constant  CHARACTER 

■  '! 

QUOTATION 

constant  CHARACTER 

#  SI 

SHARP 

constant  CHARACTER 

«'# 

DOLLAR 

constant  CHARACTER 

PERCENT 

constant  CHARACTER 

AMPERSAND 

constant  CHARACTER 

•  'k 

COLON 

constant  CHARACTER 

SEMICOLON 

constant  CHARACTER 

QUERY 

constant  CHARACTER 

•  'T 

AT  SIGN 

constant  CHARACTER 

L  BRACKET 

constant  CHARACTER 

•'1 

BACK  SLASH 

constant  CHARACTER 

R  BRACKET 

constant  CHARACTER 

•'1 

cTrcumflex 

constant  CHARACTER 

UNDERLINE 

constant  CHARACTER 

0 

CRAVE 

constant  CHARACTER 

L  BRACE 

constant  CHARACTER 

BAR 

constant  CHARACTER 

•'1 

R  BRACE 

constant  CHARACTER 

TILDE 

--  Lower  case 

constant  CHARACTER 

letters 

LC  A 

constant  CHARACTER 

•  'a' 

lc'b 

constant  CHARACTER 

«  'b' 

LC"C 

constant  CHARACTER 

-  'c' 

LC’O 

constant  CHARACTER 

•  'd' 

lc”e 

constant  CHARACTER 

«  'e' 

LC^F 

constant  CHARACTER 

■  'f' 

LC"C 

constant  CHARACTER 

.  'q' 

lc*"h 

constant  CHARACTER 

•  'h' 

LC"l 

constant  CHARACTER 

■  'i' 

LC"J 

constant  CHARACTER 

.  'J' 

lc“k 

constant  CHARACTER 

■  'k' 

lc"l 

constant  CHARACTER 

•  '1' 

lc"m 

constant  CHARACTER 

»  'm' 

lc"n 

constant  CHARACTER 

•  'n' 

LC“0 

constant  CHARACTER 

•  'o' 

LC“P 

constant  CHARACTER 

•  'p' 

lc"q 

constant  CHARACTER 

■  'q' 

lc“r 

constant  CHARACTER 

«  'r' 

LC"S 

constant  CHARACTER 

-  's' 

lc"t 

constant  CHARACTER 

-  't' 

LC“U 

constant  CHARACTER 

«  'u' 

LC“V 

constant  CHARACTER 

»  'v' 

LC”W 

constant  CHARACTER 

-  'w' 

LC“X 

constant  CHARACTER 

-  'x' 

lc“y 

constant  CHARACTER 

-  'y' 

LC“2 

constant  CHARACTER 

«  '2' 

end  ASCII; 
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— Certain  aspacts  of  the  pradafinad  antitiaa  cannot  ba  complataly 
--daacribad  in  tha  language  itaaif.  For  axampla,  although  the 
— enumeration  type  BOOLEAN  can  ba  written  showing  tha  two 
—enumeration  literals  FALSE  and  TRUE,  tha  short-circuit  control 
—forms  cannot  ba  expressed  in  tha  language. 

and  STANDARD; 
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F  4.  Restrictions  on  Representation  Clauses 

The  facilities  for  supporting  representation  clauses  are  covered  in  the  LRM,  Chapter  1 3.  The  exceptions 
are  listed  below: 

•  There  is  no  bit  level  implementation  for  any  representation  clause  in  this  implementation. 

•  The  alignment  clause  in  the  record  representation  clause  can  only  be  used  to  align  records  on  one-byte 
or  two-byte  boundaries;  this  value  must  be  specified  in  storage  units. 

•  Address  clauses  are  not  supported. 

•  Change  in  representation  for  record  types  is  not  implemented. 

•  Machine  code  insertions  are  not  implemented. 

•  For  the  length  clause: 

m  Size  specification:  T' SIZE  is  not  implemented  for  types  declared  in  a  generic  unit. 

■  Specification  of  storage  for  a  task  activation:  T'STORACE__SIZE  is  not  implemented  when  T  is  a  task 
type.  If  'STORAGE^SIZE  is  used  on  an  access  type  without  setting  a  STORACE_SIZE,  a  value  of  zero 
is  returned. 

■  Specification  of  SMALL  for  a  fixed  point  type:  T'SMALL  is  restricted  to  a  power  of  2,  and  the  absolute 
value  of  the  exponent  must  be  less  than  31. 

*.  The  enumeration  representation  clause  is  not  allowed  if  there  js  a  range  constraint  on  the  parent 
subtype. 

•  The  record  representation  clause  is  not  allowed  for  a  derived  record  type. 
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F  5.  Conventions  for  Implementation-Generated  Names 

The  names  described  in  the  following  sections  are  reserved  for  use  in  this  implementation  of  Ada  and,  in 
general,  should  not  be  used  in  your  programs. 


F  5.1  Names  for  Record  Components  and  Attributes 

The  compiler  introduces  special  implicit  record  components  for  certain  record  type  definitions.  These 
record  components  are  implementation -dependent;  they  are  used  by  the  compiler  to  improve  the  quality 
of  the  code  generated  for  certain  operations  on  the  record  types.  The  existence  of  these  components 
depends  on  implementation-dependent  criteria.  Attributes  have  been  defined  for  these  fields  for  use  in 
record  representation  clauses 

If  you  refer  to  an  implementation -dependent  attribute  that  does  not  exist,  the  compiler  issues  an  error 
message.  If  the  implementation -dependent  component  exists,  the  compiler  checks  that  the  storage  space 
specified  in  the  component  clause  is  compatible  with  the  treatment  of  this  component  and  that  the  storage 
space  of  the  other  components  is  compatible.  The  compiler  issues  an  error  message  if  this  check  fails. 

Table  F-2  lists  the  four  implementation -defined  attributes.  These  attributes  exist  only  when  the 
conditions  listed  in  the  description  are  satisfied. 


Table  F-2.  Attributes  and  Record  Types 


Attribute 

Description 

T'RECORO^SIZE 

• 

Prefix  T  denotes  a  record  type.  A  record  component  is  introduced 
by  the  compiler  in  a  record  to  store  the  size  of  the  record  object 

This  component  exists  for  objects  with  defaulted  discriminants  when 
the  sizes  of  the  record  objects  depend  on  the  values  of  the 
discriminants. 

T'VARIANTJNDEX 

Prefix  T  denotes  a  record  type.  A  record  component  is  introduced 
by  the  compiler  in  a  record  for  the  efficient  implementation  of 
discriminant  checks.  This  component  exists  for  objects  of  a  record 
type  with  variant  parts. 

C'ARRAY_DESCRIPTOR 

Prefix  C  denotes  a  record  component  of  array  type  whose 
component  subtype  definition  depends  on  discriminanta  This 
record  component  is  introduced  by  the  compiler  in  a  record  to  store 
information  on  subtypes  of  components  that  depend  on 
discriminanta 

C'RECORD_DESCRIPTOR 

Prefix  C  denotes  a  record  component  of  record  type  whose 
component  subtype  definition  depends  on  discriminanta  This 
record  component  is  introduced  by  the  compiler  in  a  record  to  store 
information  on  subtypes  of  components  that  depend  on 
discriminanta 
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Table  F-3  lists  the  four  implementation-generated  names.  These  names  are  reserved  by  the  HP  Ada/300 
implementation  and  are  not  available  for  user-created  components  in  records.  However,  these  names  are 
available  as  attributes  when  you  use  representation  clauses.  The  names  are  visible  for  records  only  when 
they  are  appropriate  to  that  record  type. 


Table  F-3.  Implementation-Generated  Names 


Names 

Description 

REC0RD_SI2E 

An  implementation-specific  record  component  This  component  is 
introduced  by  the  compiler  in  a  record  to  store  the  size  of  the  record 
object 

variant_index 

An  implementation-specific  record  component  This  component  is 
introduced  by  the  compiler  in  a  record  for  the  efficient 
implementation  of  discriminant  checks. 

ARRAY_DESCP.IPTOR 

An  internal  component  used  by  the  compiler  to  store  information 
on  subtypes  of  record  components  that  depend  upon  discriminants. 
Used  for  record  components  of  array  types. 

RECORD_DESCRIPTOR 

An  internal  component  used  by  the  compiler  to  store  information 
on  subtypes  of  record  components  that  depend  upon  discriminants. 
Used  for  record  components  of  record  typea 

F  5.2  Names  for  Predefined  Library  Units 

The  following  names  are  used  by  the  HP  Ada  Compilation  System.  Do  not  use  any  of  these  names  for 
your  library-level  Ada  onita 

ALSYS  ADA  RUNTIME 

alsys"basTc  10 

ALSYS”BINARY  10 

alsys"common"io 

ALSYS"riLE  MANAGEMENT 
ALSYS^IO  TRACES 
HIT 

MATH  EXCEPTIONS  * 

math”lib  * 
unix'env  • 

The  packages  whose  names  are  followed  by  *  axe  available  to  be  used  in  your  programs  These  packages 
are  documented  in  the  Ada  Vstr's  Guid*. 

F  6.  interpretation  of  Expressions  Appearing  in  Address  Clauses 

Address  clauses  are  not  implemented  in  this  venion  of  the  HP  Ada  compiler.  Refer  to  the  LRM,  Section 
1 3.  S  for  information  on  addren  clauses. 
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t 

F  7.  Restrictions  on  Unchecked  Type  Conversions 

Unconstrained  arrays  are  not  allowed  as  target  types.  Unconstrained  record  types  without  defaulted 
discriminants  are  not  allowed  as  target  types. 

If  the  source  and  the  target  types  are  scalar  or  access  types,  the  source  objects  must  be  the  same  siae  as  the 
target  objects. 

If  a  composite  type  is  used  either  as  source  or  as  target  type,  the  restriction  on  the  size  does  not  apply. 

If  the  source  and  the  target  types  are  each  scalar  or  access  types  or  if  they  are  both  composite  types,  the 
effect  of  the  function  it  to  return  the  operand. 

In  other  cases,  the  effect  of  unchecked  conversion  can  be  considered  as  a  copy. 

^licn  you  do  an  UNCHCCKEDjCONVCRSION  among  types  whose  sizes  do  not 
match,  the  code  which  is  generated  copies  as  many  byes  as  necessary  from 
the  source  location  to  fill  the  target  If  the  target  is  larger  than  the 
source,  the  code  copies  all  of  the  source  plus  whatever  happens  to  follow 
the  source.  So  an  UNCHCCKEO^CONVERSION  among  types  whose  sizes  do 
not  match  can  produce  meaningless  results,  or  actually  cause  a  trap  and 
abort  the  program  (if  these  memory  locations  do  not  actually  exist). 
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F  8.  Implementation-Dependent  Input-Output  Characteristics 

Section  S  covers  the  input/output  (I/O)  characteristics  of  Ada  on  the  HP  9000  Series  300  computer.  Ada 
handles  I/O  with  packages,  which  are  discussed  in  Section  F  S.  1.  File  types  are  covered  in  Section  F 
8. 1. 3.  The  FORM  parameter  is  discussed  in  detail  in  Section  F  8. 2. 


F  8.1  Ada  I/O  Packages  for  External  Files 

I/O  operations  are  considered  to  be  performed  on  objects  of  a  specific  file  type,  rather  than  being 
performed  directly  on  external  files.  An  external  file  is  a  file  external  to  the  program  that  can  produce  a 
value  to  be  read  or  receive  a  value  to  be  written.  Values  transferred  for  a  given  file  must  be  all  of  one 
type. 

Generally  in  Ada  documentation,  the  term  file  refers  to  an  object  of  a  certain  file  type,  whereas  a  physical 
manifestation  is  known  as  an  external  file.  An  external  file  is  characterized  by: 

•  Its  NAME,  which  is  a  string  defining  a  legal  pathname  under  the  current  version  of  the  operating  system. 
For  example,  the  external  file  name  myfile  may  have  the  actual  rooted  path  /PROJECT/myf  ile.  In 
that  case,  use  of  rnyfile  as  a  string  specifying  an  external  file  would  be  legal  if  the  current  working 
directory  is  /PROJECT.  See  the  example  in  Section  F  8. 1. 2. 

•  Its  FORM,  which  gives  implementation -dependent  information  on  file  characteristics. 

Both  NAME  and  FORM  appear  explicitly  in  the  Ada  CREATE  and  OPEN  procedures.  Though  a  file  is  an 
object  of  a  certain  file  type,  ultimately  the  object  has  to  correspond  to  an  external  file.  Both  CREATE  and 
OPEN  associate  the  NAME  of  an  external  file  (of  a  certain  FORM)  with  a  program  file  object 

• 

Ada  I/O  operations  are  provided  by  standard  packagea  (See  the  LRM,  Chapter  14  for  more  details.) 
Table  F-4  describes  the  standard  Ada  I/O  packages. 


Table  F-4.  Standard  I/O  Packages 


Package 

SEQUENTIAL  10 


DIRECT  10 


Description  and  LRM  Location 


A  generic  package  for  sequential  files  of  a  single  element  type.  (Section 
14.13) 


A  generic  package  for  direct  (random)  access  files  of  a  single  element  type. 


(Section  14.  IS) 


TEXT  10  A  non-generic  package  for  ASCII  text  filea  (Section  14. 3. 10) 


lO^EXCEPTIONS  A  package  which  defines  the  exceptions  needed  by  the  above  three 
packagea  (Section  14.  S) 


The  generic  package  LOW  LEVEL  10  is  not  implemented. 
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F  8.1.1  implementation-'Oependent  Restrictions  on  I/O  Packages 

The  upper  bound  for  index  values  in  DIRECT _ lO  and  for  line,  column,  and  page  numbers  in  TEXT _ lO 

is: 

COUNT 'LAST  •  2**31  -1 
The  upper  bound  for  fields’  widths  in  TEXT__IO  ic 
FIELD'LAST  ■  255 


F  8.1.2  Correspondence  between  External  Files  and  HP-UX  Files 

Ada  I/O  is  considered  in  terms  of  external  files.  Data  is  read  from  and  written  to  external  files.  Each 
external  file  is  implemented  as  a  standard  HP-UX  file.  However,  before  an  external  file  can  be  used  by 
an  Ada  program,  it  must  be  associated  with  a  file  object  belonging  to  that  program.  This  association  is 
achieved  by  supplying  the  name  of  the  file  object  and  the  name  of  the  external  file  to  the  procedures 
CREATE  or  OPEN  of  the  predefined  I/O  packagea  Once  the  association  has  been  made,  the  external  file 
can  be  read  from  or  written  to  with  the  file  object.  Note  that  for  SEQUENTIAL_IO  and  DIRECT_IO  you 
must  first  instantiate  the  generic  package  to  produce  a  non-generic  instance.  Then  you  can  use  the 
CREATE  or  OPEN  procedure  of  that  instance.  The  example  at  the  end  of  this  section  illustrates  this 
insuntiation  procesa 

The  name  of  the  external  file  can  be  either  of  the  followinr 

•  Null  string  (CREATE  only) 

•  HP-UX  pathname 

Jf  the  name  is  a  null  string,  the  associated  external  file  is  a  temporary  file,  created  using  the  HP-UX 
facility  tfflpnaiii(3).  This  external  file  will  cease  to  exist  upon  completion  of  the  prograna 

If  the  external  file  is  an  HP-UX  pathname,  the  pathname  is  extended  in  conformance  with  HP-UX  rules 
(see  intro  (2)  in  the  HP'-VX  Reference).  The  exception  USE_ERROR  is  raised  by  the  procedure  CREATE  if 
the  specified  external  file  is  a  device.  USE_ERROR  is  also  raised  for  either  OPEN  or  CREATE  if  you  have 
insufficient  acces  rights  to  the  file.  ~ 

If  an  existing  external  file  is  specified  to  the  CREATE  procedure,  the  contents  of  that  file  will  be  deleted. 
The  recreated  file  is  left  open  as  for  a  newly  created  file,  for  later  access  by  the  program  that  made  the 
call  to  create  the  file. 


NOTE 


Executing  the  procedures  and  functions  of  the  predefined  I/O  packages 
involves  the  use  of  the  Ada  run-time  system  and  the  possible  execution  of 
a  number  of  HP-UX  I/O  primitives.  When  such  primitives  are  executed, 
an  HP-UX  I/O  signal  can  be  raised  (such  signals  are  raised,  for  example,  if 
errors  are  detected  during  the  processing  of  an  I/O  primitive). 

If  certain  HP-UX  I/O  signals  are  raised,  they  are  caught  and  processed  by 
the  Ada  run-time  system.  This  processing  causes  the  appropriate  Ada 
exception  to  be  raised.  Such  Ada  exceptions  can  then  be  handled  by  the 
Ada  program. 
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EXAMPLE 


--  Exampl*  of  eraating  a  file  using  the  generic  package  DIRECT_IO 

--  The  example  also  illustrates  file  close  and  reopening  in  a  different 

--  access  mode 

with  DIRECT  10; 

with  TEXT_IO; 

procedure  RTEST  is 

package  INTIO  is  new  OIRECT_IO  (INTEGER);  —instantiate  on  INTEGER 
use  INTIO;  “  --types 

IFILE  :  INTIO. FILE_TYPE;  --  Define  a  file  object  for  reference  in  Ada 
IVALUE  :  INTEGER  :«  0;  --  Create  an  integer  element 

begin  —  RTEST 

CREATE  (  FILE  «>  IFILE,  —  Refer  to  file  object  IFILE 

MODE  ■>  INTIO. 1N0UT_FILE,  --  Set  read/write  access  mode 
NAME  ■>  "myfile"  --  Associate  an  external  file  name 

);  --  "myfile"  to  the  file  object,  IFILE 

TEXT_IO.PUT_LINE  ("Created  A  INTIO.NAME  (IFILE)); 

CLOSE  (  FILE  »>  IFILE);  --  Close  the  external  file 

TEXT_^IO.PUT_,LINE("Closed  file"); 

OPEN  (FILE  «>  IFILE,  —  Open  the  file  object 

MODE  «>  INTIO. Oin-^FILE,  —  in  the  new  MODE  to  allow  write  only 

NAME  ■>  "myfile"  ”  —  Associate  an  external  file  name 

);  —  "myfile"  to  the  file  object.  IFILE 

TEXTJO.Pirr_LlNE("Opened  (new  mode)  A  INTIO.NAME  (IFILE)); 

INTIO. WRITE  (IFILE.  IVALUE)  ;  —  Write  an  Integer  to  the  file 

TEXT_IO,PUT_LINE( "Appended  an  Integer  to;"  A  INTIO.NAME  (IFILE)); 

CLOSE  (  FILE  ■>  IFILE); 

TEXT_IO.PUT_LINE("Close  file"); 

end  RTEST; 

In  the  example  above,  the  file  object  is  IFILE,  the  external  file  name  relative  to  your  current  working 
directory  is  myfile,  and  the  actual  rooted  path  could  be  /PROJECT/myfile.  Error  or  informational 
messages  from  the  Ada  development  system  (compiler,  tools)  may  mention  the  actual  rooted  path. 


NOTE 


The  Ada/ 300  development  system  manages  files  internally  so  that  names 
involving  symbolic  links  (see  ln(1))  are  mapped  back  to  the  actual  rooted 
path.  Consequently,  when  the  development  system  interacts  with  files 
involving  symbolic  links,  the  actual  rooted  pathname  may  be  mentioned  in 
informational  or  error  messages  rather  than  the  symbolic  name. 
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F  8.1.3  Standard  Implementation  of  External  Files 

External  files  have  a  number  of  implementation -dependent  characteristics,  such  as  their  physical 
orsanization  and  file  access  rights.  It  is  possible  to  customize  these  characteristics  through  the  FORM 
parameter  of  the  CREATE  and  OPEN  procedures,  described  fully  in  Section  F  8. 2.  The  default  of  FORM  is 
the  null  string.  The  following  section  describes  the  standard  or  default  implementation  of  three  types  of 
external  filec  sequential,  direct,  and  text.  Default  protection  for  external  files  is  also  described. 


NOTE 


In  the  absence  of  the  FORM  parameter,  default  protection  is  a  function  of 
the  HP-UX  operating  system  (see  Section  F  8.2  which  follows). 


F  8. 1.3.1  Sequential  Files 

A  sequential  file  it  a  sequence  of  values  that  are  transferred  in  the  order  of  their  appearance  (u  produced 
by  the  program  or  by  the  run-time  environment).  A  file  is  a  collection  of  data  elements  (object 
components)  of  identical  type.  Each  object  in  a  sequential  file  has  exactly  the  same  binary  representation 
at  the  Ada  object  in  the  executable  program. 

The  information  placed  in  a  sequential  file  depends  on  whether  the  type  used  for  the  instantiation  of  the 
sequential  I/O  package  is  constrained  or  unconstrained.  If  it  it  constrained,  the  objects  are  put 
consecutively  into  the  file,  without  holes  or  separaton.  If  the  type  it  unconstrained,  the  length  of  the 
object  (in  bytes)  is  added  to  the  front  of  the  object  as  a  32-bit  integer  value.  See  Section  F  8.15  for  a 
detailed  description.  The  default  it  that  there  is  no  buffer  between  the  physical  external  file  and  the  Ada 
program.  However,  see  Section  F  8. 1 6  for  details  on  specifying  a  file  BUFFER  SIZE 


F  8.1.3.2  Direct  Flies 

A  direct  access  file  it  a  set  of  elements  occupying  consecutive  positions  in  a  linear  order.  The  position  of 
an  element  in  a  direct  file  is  specified  by  its  index,  which  is  an  integer  in  the  range  1  to  (2**3  D-l  of 
subtype  POSITIVE_COUNT.  If  the  file  is  created  with  the  default  FORM  parameter  attributes  (tee  Section 
F  8. 2),  only  objects  of  a  constrained  type  can  be  written  to  or  read  from  a  direct  access  file.  Such  objects 
have  exactly  the  tame  binary  representation  as  the  Ada  object  in  the  executable  program.  Although 
instantiation  of  DIRECT_^IO  is  accepted  for  unconstrained  types,  the  exception  USE_ERROR  is  raised  on  any 
call  to  CREATE  or  OPEN  where  the  object  is  of  an  unconstrained  type.  Using  theToRM  parameter  allows 
you  to  store  unconstrained  objects  in  a  direct  acces  file  by  specifying  the  maximum  RECORO_SIZE  of 
unconstrained  types. 

A  file  is  a  collection  of  data  elements  (object  components)  of  identical  type.  All  elements  within  the  file 
have  the  same  length.  The  number  of  bytes  occupied  by  each  element  is  determined  by  the  size  of  the 
object  stored  in  the  file.  The  default  is  that  there  is  no  buffer  between  the  physical  external  file  and  the 
Ada  program.  See  Section  F  8. 1 6  for  details  on  specifying  a  file  BUFFER  SIZE 
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'  F  8.1.3.3  Text  Fite's 

Text  files  are  used  for  the  input  and  output  of  information  which  is  in  a  readable  form.  Each  text  file  is 
read  or  written  sequentially,  as  a  sequence  of  characten  grouped  into  lines,  and  as  a  sequence  of  lines 
grouped  into  pagea  All  text  file  column  numbers,  line  numbers,  and  page  numbers  are  in  the  range  1  to 
(2**3 1)-1  of  subtype  POSITlVE__COUNT.  The  line  terminator  (end-of-line)  is  physically  represented  by 
the  ASCII  character  ASCII.LF.  The  page  terminator  (end-of-page)  it  physically  represented  by  a 
succession  of  the  two  characters,  ASCII.LF  and  ASCII.FF,  in  that  order.  The  file  terminator 
(end-of-file)  it  physically  represented  by  the  character  ASCII.LF,  followed  by  the  HP-UX 
END-OF-FILC.  See  Section  F  S.  1 5  in  this  appendix  for  more  information  about  structuring  text  filea 

If  you  control  line,  page,  and  file  structure  by  calling  predefined  subprograms  (LRM,  Section  1 4. 3. 4),  you 
need  not  be  concerned  with  the  above  terminator  implementation  detaila  If  you  effect  structural  control 
by  explicitly  inputting  or  outputting  these  control  characters  (via  the  PUT  function,  for  example),  it  is 
your  responsibility  to  maintain  the  integrity  of  the  externa]  file.  The  standard  implementation  of  text 
files  does  not  buffer  text  file  I/O.  However,  buffering  is  a  device -dependent  characteristic  that  can  be 
modified  at  the  system  level  (for  example,  to  buffer  lines  of  text  entered  from  a  terminalX 


CAUTION 


If  a  terminal  it  used  for  text  input,  the  functions  END  OF  PACE  and 
END  OF  FILE  always  return  FALSE. 


F  8.1.4  Default  Access  Protection  of  External  Files 

HP-UX  provides  protection  of  a  file  by  means  of  access  rights.  These  access  rights  are  used  within  Ada 
programs  to  protect  external  filea  There  are  three  levels  of  protection: 

•  User  (the  owner  of  the  fileX 

•  Croup  (users  belonging  to  the  owner’s  group). 

•  Others  (users  belonging  to  other  groupsX 

For  each  of  these  levels,  access  to  the  file  can  be  limited  to  one  or  several  of  the  following  rights:  read, 
write,  or  execute.  The  standard  external  file  access  rights  are  specified  by  the  UHASK  command  (see 
umaek(  1 )  and  umaek{2)  in  the  HP-UX  Reference).  Access  rights  apply  equally  to  sequential,  direct,  and 
text  filea  See  the  section  on  the  FORM  parameter  (F  8.2)  for  information  a^ut  specifying  file  permissions 
at  the  time  of  CREATE. 


F  8.1.5  The  Sharing  of  External  Files  and  Tasking  Issues 

Several  file  objects  can  be  associated  with  the  same  external  file.  The  objects  can  have  identical  or 
differing  I/O  rooder,  each  file  object  has  independent  access  to  the  external  file.  The  effects  of  sharing  an 
external  file  depend  on  the  nature  of  the  file.  You  must  keep  in  mind  the  nature  of  the  device  attached 
to  the  file  object  and  the  sequence  of  I/O  operations  on  the  device.  Multiple  I/O  operations  on  an 
external  file  shared  by  several  file  objects  are  processed  in  the  order  they  occur. 

In  the  case  of  shared  files  on  random  accen  devices,  such  ss  discs,  the  data  is  shared.  Reading  from  one 
file  object  does  not  affect  the  file  positioning  of  another  file  object,  nor  the  data  available  to  it.  However, 
simultaneous  reading  and  writing  of  separate  file  objects  to  the  same  random  access  external  file  (a  direct 
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access  file,  for  example)  should  be  avoided;  due  to  buffering,  the  effects  are  unpredictable.  File  buffering 
may  be  enabled  by  using  the  FORM  parameter  attributes  at  the  time  you  open  or  create  the  file. 

In  the  case  of  shared  files  u  sequential  or  interactive  devices,  such  as  magnetic  tapes  or  keyboards,  the 
data  is  no  longer  shared.  In  other  words,  a  magnetic  record  or  keyboard  input  buffer  read  by  one  I/O 
operation  is  no  longer  available  to  the  next  operation,  whether  it  it  performed  on  the  tame  file  object  or 
not.  This  it  simply  due  to  the  sequential  nature  of  the  device.  By  default,  file  objects  represented  by 
STANDARO^IN  and  STANOARO_^OUT  are  preconnected  to  the  HP-UX  streams  aid  in  and  atdout  (see 
stdio(5)),  and  thus  are  of  this  sequential  variety  of  file.  The  HP-UX  stream  atderr  is  not  preconnected 
to  an  Ada  file  but  is  used  by  the  Ada  run-time  system  for  error  messages. 

Each  file  operation  is  completed  before  a  subsequent  file  operation  commences.  In  a  tasking  program,  this 
means  no  explicit  synchronization  needs  to  be  performed  unless  the  order  of  I/O  operations  is  critical  An 
Ada  tasking  program  is  erroneous  if  it  depends  on  the  order  of  I/O  operations  without  explicitly 
synchronizing  them.  Remember  that  the  files  associated  with  STANDARD_IN  and  STANOARO^OUT  are 
shared  by  all  tasks,  and  that  care  must  be  taken  when  Ada  file  objects  use  buffered  I/O. 


NOTE 


The  sharing  of  external  files  discussed  here  is  system-wide  and  is  managed 
by  the  HP-UX  operating  system.  Several  programs  may  share  one  or  more 
external  filea  The  file  sharing  using  the  FORM  parameter  SHARED,  which  is 
disctissed  in  F  8. 1 4,  is  not  system-wide,  but  is  a  file  sharing  within  an  Ada 
program  and  is  managed  by  that  program  Synchronized  access  to  a  file 
shared  using  the  FORM  parameter  SHARED  is  your  responsibility. 


F  8.1.6  I/O  Involving  Access  Types 

When  an  object  of  an  access  type  is  specified  u  the  source  or  destination  of  an  I/O  operation  (read  or 
write),  the  32-bit  binary  access  value  is  read  or  written  unchanged.  If  an  access  value  is  read  from  a  file, 
take  care  to  ensure  that  the  access  value  so  read  designates  a  valid  object  This  is  only  likely  to  be  the 
case  if  the  access  value  read  wu  previously  written  by  the  same  program  that  is  reading  it,  and  the  object 
which  it  designated  at  the  time  it  was  written  still  exists  (that  is,  the  scope  in  which  it  was  allocated  hu 
not  been  exited,  nor  hu  an  UNCHECKED_DEALLOCATION  been  performed  on  it).  A  program  may  execute 
erroneously  if  an  access  type  read  from  Tfile  does  not  designate  a  valid  object 


F  8.1.7  I/O  Involving  Local  Area  Networks 


This  section  assumes  knowledge  of  both  remote  file  access  and  networka  It  describes  Ada  program  I/O 
involving  two  Local  Area  Network  (LAN)  services  available  on  the  Series  300  computerr 

1.  RFA  systems:  remote  file  accen  (RFA)  using  the  NS/9000  network  services  software. 

9 

2.  NFS  systems:  remote  file  access  using  the  NFS  network  services  software. 


NFS 


is  a  trademark  of  SUN  Microsystems,  Inc. 
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The  Ada  programs  discussed  here  are  executed  on  a  local  (host)  computer.  These  programs  accen  or  create 
files  on  a  remote  system,  which  is  located  on  a  mass  storage  device  not  directly  connected  to  the  host 
computer.  The  remote  file  system  can  be  mounted  and  accessed  by  the  host  computer  using  RFA  or  NFS 
LAN  services.  RFA  systems  are  described  in  Network  Services/9000  LAN  User’s  Guide  for  HP  9000 
Computers.  NFS  systems  are  '^escribed  in  Using  and  Administering  NFS  Services. 

Note  that  Ada  I/O  can  be  used  reliably  across  local  area  networks  using  RFA  only  if  the  network  special 
files  representing  remote  file  systems  are  contained  in  the  directory  /net,  as  is  customary  on  HP-UX 
systema  See  the  HP-UX  System  Administrator  Manual  (for  the  Series  300)  for  more  details. 


F  8.1.7.1  RFA  Systems 

Properly  specified  external  files  can  be  created  or  accessed  reliably  from  Ada  programs  across  the  LAN  on 
RFA  systema  You  can  create  or  access  a  file  only  if  an  RFA  connection  exists  from  the  remote  file 
system  at  the  time  your  Ada  program  is  executed.  The  example  on  the  following  page  illustrates  remote 
file  access  and  use. 

In  this  example,  a  remote  network  connection  to  a  system  hpelada  is  assumed.  This  connection  could 
have  been  made  by  typing,  for  example,  (where  $  is  the  shell  prompt), 

$  r^tunam  /n«t/hpclada  userjiaim: 

Password:  user joassud 

$ 


EXAMPLE 


with  OIRECTJO; 

procsdur*  LANTEST  is  , 

—  instant lets  the  ganarie  packaga  DIRECT^IO 
--  for  filas  whosa  cornponant  typa  is  INTEGER, 
packaga  TESTIO  is  naw  DIRECTJO(INTECER) ; 
usa  TESTIO; 

REMOTE^FILE  :  TESTIO. FILE JYPE; 

IVALUE  :  INTEGER  ;•  0  ; 

RVALUE  ;  INTEGER  :•  -1  ; 

.  bagin 


--  craata  s  ramota  fila 

TEST 10. CREATE  (FILE  ■>  REMOTE  FILE, 

MODE  »>  TESTI07oUT_FILE,  —OUT  moda  for  DIRECT^IO 
NAME  ■>  ''/nat/hpclada/projact/tast.f  ila") ; 

—  Closa  tha  fiia 

TESTIO.CLOSE  (FILE  »>  REMOTE^FILE) ; 

--  Ra-opan  tha  fila  with  diffarant  fila  moda 
TESTIO. OPEN  (FILE  »>  REMOTE  FILE, 

MODE  ■>  TESTI0TiN0UT_FILE,  --IN0UT  moda  for  D1RECT_I0 
NAME  ■>  "/nat/hpclads/project/tast.f ila") ; 


B-29 


ImplemenUtioxi'Dependent  Charactenstics 


•-  Writ*  «n  integer  (0)  to  the  file 
TESTIO. WRITE  (REMOTE_FlLE,  IVALUE); 

—  Reset  the  file  pointer  in  the  file 
TESTIO. RESET  ( REMOTEST I LE ) ; 

Reed  from  the  file,  rvalue  should  now  be  zero 
TESTIO. READ  (REMOTE_riLE.  RVALUE); 

--  Close  the  file 

CLOSE  (FILE  »>  REMOTE^FILE); 

end  LANTEST; 


F  8.1.7.2  NFS  Systems 

If  an  Ada  program  expects  to  access  or  create  a  file  on  a  remote  file  system  using  NFS  LAN  services,  the 
remote  volumes  which  contain  the  file  system  must  be  mounted  on  the  host  computer  prior  to  the 
execution  of  the  Ada  program. 

For  example,  assume  that  the  remote  system  (hpclade)  exports  a  file  system  /project,  /project  is 
mounted  on  the  host  computer  as  /ada/project.  Files  in  this  remote  file  system  are  accessed  or  created 
by  references  to  the  files  as  if  they  were  part  of  the  local  file  system.  To  access  the  file  last. file,  the 
program  would  reference  /ada/projact/taat.fila  on  the  local  system.  Note  that  taat.f  ila  appears 
as  /projact/taat.fila  on  the  remote  system.  The  netuwani  1)  command  (from  HP’s  NS/9000)  is  not 
used  in  NFS. 

The  remote  file  system  must  be  exported  to  the  local  system  before  it  can  be  locally  mounted,  using  the 
mount  ( 1(ti)  command.  ' 


F  8.1.8  Implementation-Defined  i/0  Packages 

UNIX_ENV  is  the  only  implementation-defined  I/O  package.  An  Ada  program  that  does  not  use  UNIX_ENV 
has  no  implicit  access  to  its  execution  environment  without  using  the  package  UNIX_ENV.  In  particular, 
there  is  no  direct  equivalent  to  the  arge  and  argv  parameters  of  a  C  Language  main  program.  In  this 
implementation,  parameters  cannot  be  passed  to  a  procedure  used  as  an  Ada  main  program  unless  the 
HP-supplied  package  UNIX_ENV  is  used.  The  binder  will  not  bind  a  program  with  parameters  in  its  main 
program.  The  implementation-defined  package  UNIX_ENV  enables  an  Ada  program  to  retrieve 
information  from  the  HP-UX  environment.  The  specification  of  UNIX_ENV  is  listed  in  the  Ada  User's 
Guide. 


F  8.1.9  Polential  Problems  With  I/O  From  Ada  Tasks 

In  an  Ada  tasking  environment  on  the  HP  9000  Series  300,  the  Ada  run  time  provides  some  protection  of 
file  objects  against  attempts  to  perform  multiple  simultaneotu  I/O  operations  on  the  same  logical 
(internal)  file.  (Note  that  this  is  not  the  tame  as  the  sharing  of  an  external  file  through  multiple  internal 
files  which  is  supported  in  a  controlled  fashion  by  the  use  of  the  FORM  parameter  in  CREATE  or  OPEN 
calla)  When  multiple  tasks  attempt  to  share  an  internal  file  without  proper  synchronization,  intermixing 
of  two  I/O  operations  on  the  same  internal  file  (an  Ada  file  object)  can  occur  due  to  task  scheduling.  If 
such  a  situation  exists  and  two  I/O  operations  collide,  PROCRAM_ERROR  will  be  raised  by  the  Ada  I/O 
package. 


B-30 


ImplexnenUtiOQ  "Dependent  Charactehstict 


CAUTION 


It  is  your  responsibility  to  utilize  proper  synchronization  and  mutual 
exclusion  in  the  use  of  shared  resources.  Note  that  shared  access  to  a 
common  resource  (in  this  case,  a  file)  could  be  achieved  by  rendezvous 
between  tasks  that  share  that  resource.  If  you  write  a  program  in  which 
two  tasks  attempt  to  perform  I/O  operations  on  the  same  logical  file 
without  proper  synchronization,  that  program  is  erroneous.  (See  LRM, 
Section  9.11.) 


F  8.1.10  I/O  Involving  Symbolic  Links 

Some  caution  must  be  exercised  when  using  an  Ada  program  that  performs  I/O  operations  to  files  that 
involve  symbolic  links.  (For  more  detail  on  the  use  of  symbolic  links  to  files  in  HP-UX 

Creating  a  symbolic  link  to  a  file  creates  a  new  name  for  that  file  that  is,  in  effect,  an  alias  for  the  actual 
file  name.  If  you  use  the  actual  file  name  or  its  alias  (that  is,  the  name  involving  symbolic  links),  Ada  I/O 
operations  will  work  correctly.  However,  the  NAME  function  (in  the  TEXT_^IO,  SEQUENTIAL__10,  and 
OIRECT_IO  packages)  will  always  return  the  actual  rooted  path  of  a  file  and  not  a  path  involving 
symbolic  links. 
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F  8.2  The  FORM  Parameter 

For  both  the  CREATE  and  OPEN  procedures  in  Ada,  the  FORM  parameter  specifies  the  characteristics  of  the 
external  file  involved. 

The  CREATE  procedure  establishes  a  new  external  file  of  a  given  NAME  and  FORM,  and  associates  with  it  a 
specific  program  FILE  object  The  external  file  is  created  (and  the  FILE  object  set)  with  a  certain  file 
MODE.  If  the  file  already  exists  with  the  same  NAME  as  stated  in  the  CREATE  call,  the  file  will  be  erased 
and  then  recreated.  The  exception  USE^ERROR  is  raised  if  the  file  mode  is  IN^FILL 

If  you  execute  an  Ada  program  containing  a  CREATE  statement,  you  must  have  adequate  permission  for 
file  creation  in  HP-UX.  Otherwise,  the  CREATE  procedure  will  raise  STATUS_ERROR  or  USE_ERROR  on 
attempts  to  recreate  (erase)  an  existing  file  (regardless  of  the  FORM  parameter  setting  permissions).  For 
example,  an  existing  file  with  no  read,  write,  or  execute  permission  for  the  user  who  executes  such  an  Ada 
program  (one  which  attempts  to  create  a  file  by  the  same  name),  will  raise  STATUS^ERROR  or  USE_ERROR 

The  OPEN  procedure  associates  an  existing  external  file  of  a  given  NAME  and  FORM,  with  a  specified 
program  FI  LE  object  The  procedure  also  sets  the  current  FI  LE  mode.  If  there  is  an  inadmissible  change 
of  MODE,  an  Ada  USE  ERROR  is  generated. 


F  8.2.1  An  Overview  of  FORM  Attributes 

The  FORM  parameter  is  composed  from  a  list  of  attributes  that  specify 

•  File  protection 

•  File  sharing 

«  File  structuring 

•  Buffering 

•  Appending 

•  Blocking 

•  Terminal  Input 


F  8.2.2  The  Format  of  FORM  Parameters 

Attributes  of  the  FORM  parameter  have  a  keyword  followed  by  the  Ada  "arrow  symbol”  (■>)  (see  LRM, 
Section  1 2(  1 0)),  followed  by  qualifier.  The  qualifier  and  arrow  symbol  may  sometimes  be  omitted.  Thus, 
the  format  for  an  attribute  specifier  is 

KEYWORD 

or 

KEYWORD  «>  QUALIFIER 
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The  general  format  for  the  FORM  parameter  is  a  string  formed  from  a  list  of  attributes,  with  attributes 
separated  by  commas  (J.  The  string  is  not  case  sensitive.  The  arrow  symbol  can  be  separated  by  spaces 
from  the  keyword  and  qualifier.  The  two  forms  below  are  equivalent 

KEYWORD  «>  QUALIFIER 

KEYWORD •>QUALIFIER 

In  some  cases,  an  attribute  can  have  multiple  qualifiers  that  can  be  presented  at  the  same  time.  In  cases 

that  allow  multiple  qualifiers,  additional  qualifiers  are  introduced  with  an  underscore  ( _ X  Note  that 

spaces  are  not  allowed  between  the  additional  qualifiers;  only  underscore  characters  are  allowed. 
Otherwise,  a  USE_CRROR  exception  it  raised  by  CRCATL  The  two  examples  that  follow  illustrate  the 
FORM  parameter  format 

The  first  example  illustrates  the  use  of  the  FORM  parameter  in  the  TEXT_IO.OPEN  to  set  the  file  buffer 
size.  ” 


—  Example  of  opening  a  file  using  the  non-generic  package  TEXT  10. 

—  This  illustrates  the  use  of  the  FORM  parameter  BUFFER_SIZE 

—  Note:  "inpt^^file"  must  exist,  or  NAME^^ERROR  will  be  raised. 

with  TEXT_IO; 
procedure”STEST  is 

TFILE  :  TEXT^IO.FILE_TYPE;  --Define  a  file  object  for  reference  in  Ada 
begin  —  STEST 

TEXT^^IO.OPEN  (file  •>  TFILE,  —  Refer,  to  file  object  created  above 

MODE  •>  TEXT^IO.IN  FILE,  —Set  mode  for  READ  access  only 
NAME  •>  "inpt  file^,  —  Associate  an  external  file  name 
—  “inpt^file"  to  the  file  object:  TFILE 
FORM  *>  "BUFFER  SIZE  »>4096”--set  buffer  size  to  4K  bytes 
); 


end  STEST; 

The  second  example  illustrates  the  use  of  the  FORM  parameter  in  TEXT^IO. CREATE.  This  example  sets  the 
access  rights  of  the  owner  (HP-UX  file  permissions)  on  the  created  file*and  shows  multiple  qualifiers  being 
presented  at  the  same  time. 

TEXT_IO. CREATE  (OUTPUT  FILE,  TEXT__IO.OUT_FILE,  OUTPUT_FILE_NAME, 
FORM»>%wnsr«>rsad^writ#  axacuta"};  ”  ” 
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F  8.2.3  The  FORM  Parameter  Attribute  -  File  Protection 

The  file  protection  attribute  it  only  meaningful  for  a  call  to  the  CREATE  procedure. 

File  protection  involves  two  independent  classifications.  The  first  classification  specifies  which  user  can 
access  the  file  and  is  indicated  by  the  keywords  listed  in  Table  F-5. 

Table  F-5.  User  Access  Categories 


Category 

Grants  Access  To 

OWNER 

Only  the  owner  of  the  created  file. 

CROUP 

Only  the  members  of  a  defined  group. 

WORLD 

Any  other  users. 

Note  that  WORLD  is  similar  to  “others"  in  HP-UX  terminology,  but  was  used  in  its  place  because  OTHERS  is 
an  Ada  reserved  word. 

The  second  classification  specifies  access  rights  for  each  classification  of  user.  The  four  general  types  of 
access  rights,  which  are  specified  in  the  FORM  parameter  qualifier  string,  are  listed  in  Table  F-6. 

Table  F-€.  File  Access  Rights 


Category 

Allows  the  User  To 

READ 

Read  from  the  external  file. 

WRITE 

Write  to  the  extersn*  file. 

EXECUTE 

Execute  a  program  stored  in  the  external  file. 

NONE 

The  user  has  no  access  rights  to  the  external  file.  (This 

qualifier  overrides  any  prior  privileges. ) 

More  than  one  access  right  can  be  specified  for  a  particular  file.  Additional  access  rights  can  be  indicated 
by  separating  them  with  an  underscore  as  noted  earlier.  The  following  example  using  the  FORM  parameter 
in  TEXT_IO.  CREATE  sets  access  rights  of  the  owner  and  other  users  (HP-UX  file  permissions)  on  the 
created  file.  This  example  illustrates  multiple  qualifiers  being  used  to  set  several  permissions  at  the  same 


TEXTJO. CREATE  (OUTPUT  FILE,  TEXT_IO.OUT_FILE,  OUTPUT_FILE_NAME, 
FORM* >%wner«> read  write  execute,  woPld*>none*') ; 
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Note  that  the  HP-UX  umaek(l)  and  umatk(2)  commands  may  have  set  the  default  rights  for  any 
unspecified  permissions  In  the  previous  example,  permission  for  the  users  in  the  category  GROUP  were 
unspecified.  Typically,  the  default  umaak  will  W  set  so  that  the  default  allows  newly  created  files  to  have 
read  and  write  permission  -  and  no  execute  permission  -  for  each  category  of  user  (USER,  CROUP,  and 
WORLD). 

Consider  the  case  where  the  usen  in  WORLD  want  to  execute  a  program  in  an  external  file,  but  only  the 
owner  may  modify  the  file. 

The  appropriate  FORM  parameter  is  then: 

WORLD  ->  EXECUTE, 

OWNER  ■>  READ__WRITE_,EXECUTE 

This  would  be  applied  as: 

TEXT_IO. CREATE  (OUTPUT  FILE,  TEXT_IO.OUT_FILE,  OUTPUT__FILE_NAME, 

FORM«>^worlds>«xacut«,  owner«>read_write_execute'’) ; 

Repetition  of  the  same  qualifier  within  attributes  is  illegal: 

WORLD  «>  EXECUTE_EXECUTE  —  NOT  logal 

But  repetition  of  entire  attributes  is  allowed: 

WORLD  •>  EXECUTE,  WORLD  «>  EXECUTE  —  legal 


F  6.2.4  The  FORM  Parameter  Attribute  -  File  Sharing 

The  file  sharing  attribute  of  the  FORM  parameter  provides  control  over  multiple  access  to  a  given  external 
file  from  within  an  Ada  program.  For  example,  the  controlled  file  sharing  could  be  among  separate  Ada 
tasks.  The  control  over  multiple  access  does  not  extend  to  the  whole  system.  See  Section  F  8. 1.  S  for 
details  on  file  sharing  at  the  system  level  between  separate  programs  for  more  details.  The  HP-UX 
operating  system  controls  file  sharing  at  the  system  level;  the  programmer  controls  the  file  sharing 
described  here.  File  sharing  with  the  FORM  parameter  occurs  within  a  single  Ada  program. 

An  external  file  can  be  shared;  that  is,  the  external  file  can  be  associated  simultaneously  with  several 
logical  file  objects  created  by  the  OPEN  or  CREATT  procedurea  The  file  sharing  attribute  restricts  or 
suppresses  this  capability  by  specifying  one  of  the  modes  listed  in  Table  F-7. 
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Table  F-7.  File  Sharing  Attribute  Modes 


Mode 

Description 

NOT_SHARED 

Indicates  exclusive  acces!  No  other  logical  file  can  be 
associated  with  the  external  file. 

SHARED* > READERS 

Only  logical  files  of  mode  IN  can  be  associated  with  the 
external  file. 

SHARED*  >SI NCLE_WRITER 

Only  logical  files  of  mode  IN  and  at  most  one  file  with 
mode  OUT  can  be  associated  with  the  external  file. 

SHARED*) ANY 

No  restrictions;  this  is  the  default. 

A  USC_ERROR  exception  is  raised  if  either  of  the  following  conditions  exists  for  an  external  file  already 
associated  with  a  logical  Ada  file: 

•  A  further  OPEN  or  CREATE  specifies  a  file  sharing  attribute  different  from  the  current  one. 

•  A  further  OPEN,  CREATE,  or  RESET  violates  the  conditions  imposed  by  the  current  file  sharing 
attribute. 

The  restrictions  imposed  by  the  file  sharing  attribute  disappear  when  the  last  logical  file  linked  to  the 
external  file  is  closed.  The  default  ANY  allows  multiple  writen  tp  a  file.  Specifying  ANY  can  produce  an 
unexpected  sequence  of  output  operation!  Tasking  programs  should  use  synchronization  via  rendezvous  to 
prevent  problems  that  may  arise  in  accessing  a  shared  file.  (See  Section  F  8. 1.9.) 
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F  8.2.5  The  FORM  Parameter  Attribute  -  File  Structuring 

This  section  describes  how  to  structure  your  files. 


F  8.2.5.1  Text  Files 

There  is  no  FORM  parameter  to  define  the  structure  of  text  files.  A  text  file  consists  of  a  sequence  of  bytes 
containing  ASCII  character  codes. 

You  can  control  Ada  terminators  explicitly  in  text  files.  The  representation  of  Ada  terminators  depends 
on  the  file’s  mode  (IN  or  OUT)  and  whether  it  is  associated  with  a  terminal  device  or  a  mass-storage  file. 
See  Table  F-8  which  follows. 

Tabic  F-8.  Text  File  Terminators 


File  Type 

Terminator 

Mass-storage  files 

•nd  of  lino:  ASCII.LF 

•nd  of  page:  ASCII.LF  ASCII.FF 

•nd  of  fiU:  ASCII.LF  ASCI  I.  EOT 

Terminal  device/  IN  mode 

•nd  of  lino:  ASCII.LF 

•nd  of  pago:  ASCII.LF  ASCII.FF 

•nd  of  fllo:  ASCII.LF  ASCII.FF 

Terminal  device/  OUT  mode 

•nd  of  lino:  ASCII.LF 
•nd  of  pago:  ASCII.FF 
•nd  of  filo:  ASCI I. EOT 

See  Section  F  8. 1. 3. 3  for  more  information  about  terminators  in  text  filea 


F  8  2.5.2  Binary  Files 

This  section  describes  use  of  the  FORM  parameter  for  binary  (sequential  or  direct  access)  filea  Two  FORM 
attributes,  RECORO^SIZC  and  RCCORO^UNIT,  control  the  structure  of  binary  filea 

Such  a  file  can  be  viewed  as  a  sequence  or  a  set  of  coiuecutive  RECORDS.  The  structure  of  a  record  is 

[  HEADER  1  OBJECT  [  UNUSED_PART  ) 

A  record  is  composed  of  up  to  three  items: 

1.  A  HEADER  consisting  of  two  fields  (each  of  32  bits) 

•  The  length  of  the  object  in  bytea 

•  The  length  of  the  descriptor  in  bytea 

2.  An  OBJECT  with  the  exact  binary  representation  of  the  Ada  object  in  the  executable  program,  possibly 
including  an  object  descriptor. 
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3.  An  UNUSED_PART  of  variable  size  to  permit  full  control  of  the  record’s  size. 

The  HtADCR  is  implemented  only  if  the  actual  parameter  of  the  instantiation  of  the  I/O  package  is 
unconstrained. 

The  file  structure  attributes  take  the  form: 

RECORD^SIZE  ■>  eiz«_ln_^byt*e 
RECORD_UNIT  ■>  aiz«_in_byt«e 

The  attributes’  meaning  depends  on  the  object’s  type  (constrained  or  unconstrained)  and  the  file  access 
mode  (sequential  or  direct  accea). 

The  two  types  of  access  are: 

•  Sequential  access  of  consecutive  RECORDS 

•  Direct  access  of  consecutive  RECORDS 

The  consequences  of  this  are  shown  in  Table  F-9  on  the  following  page. 
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Table  F-9.  Structuring  Binary  Files  With  the  FORM  Parameter 


Object  Type 

File  Access 
Mode 

RECORD_UNIT 

Attribute 

RECORD__SIZE 

Attribute 

Constrained 

Sequential  I/O 

The  RECORD^UNIT  attribute 
is  illegal 

If  the  RECORD_SIZE 
attribute  is  omitted,  no 
UNUSED_PART  is 
implemented.  The  default 
RECORO_SIZE  is  the  object’s 
size.  ” 

If  present,  the  RECORD_SIZE 
attribute  must  specify  a 
record  size  greater  than  or 
equal  to  the  object’s  size. 
Otherwise,  the  exception 
USE_ERROR  is  raised 

Unconstrained 

Sequential  I/O 

By  default,  the 

RECORD_UNIT  attribute 
is  one  byte. 

The  RECORO_SIZE  attribute 
it  illegal 

The  size  of  the  record  is  the 
smsdlest  multiple  of  the 
ti>ecified  (or  default) 
RECORO^UNIT  that  holds 
the  objKt  and  its  length. 

This  is  the  only  case  where 
record  of  a  file  can  have 
different  sizea 

Direct  I/O 

The  RECORO_UNIT  attribute 
is  illegal 

The  RECORD_^SIZE  attribute 
has  no  default  value,  and  if 
a  value  is  not  specified,  a 
USE^ERROR  is  raised 

If  you  attempt  to  input  or 
output  an  object  larger  than 
the  given  RECORD_SIZE,  a 
DATA_^ERROR  exception  is 
raised 

If  you  CREATE  a  direct  access  file  with  the  default  FORM  parameter,  then  only  objects  of  a  constrained 
type  can  be  written  to  or  read  from  that  direct  access  file. 


I 
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F  8.2.6  The  FORM  Parameter  Attribute  -  File  Buffering 

The  buffer  size  can  be  specified  by  the  attribute: 

BUrFER__SIZE  »>  «iz«__in_byt*« 

The  default  value  for  BUFFER_SI2E  it  Ofor  terminal  devices  (which  means  no  buffering),  and  I _ sector 

for  disc  filea  Using  the  file  buffering  attribute  can  improve  I/O  performance  in  some  cases. 

An  example  of  the  use  of  the  FORM  parameter  in  the  TEXT_IO.OPEN  to  set  the  file  buffer  size  it  shown 
below:  “ 


—  Example  of  creating  a  file  using  the  non-generic  package  TEXT__IO 
--  This  illustrates  the  use  of  the  FORM  parameter  BUFFER^SIZE 

with  TEXTJO; 
procedure  T_TEST  is 

BFILE  ;  TEXT_IO.FILE  TYPE;  —  Define  a  file  object  for  reference  in  Ada 


begin  —  T  TEST 


TEXT  10. CREATE 


(FILE  ■>  BFILE«  --  Refer  to  file  object  created  above 
MODE  ■>  TEXT_IO.OUT_FILE,  —  Set  WRITE  access  only  mode 
NAME  *>  “txt  file*‘«  --  Associate  an  external  file  name 
—  "txt  file"  to  the  file  object:  BFILE 
FORM  •>  "BUFFER  SIZE»>ei9Z”— set  buffer  size  to  8K  bytes 
); 


end  TJ'EST; 

F  8.2.7  The  FORM  Parameter  ■*  Appending  to  a  File 
The  APPEND  attribute  can  only  be  used  with  the  procedure  OPEN.  Its  format  is 
APPEND 

Any  output  will  be  placed  at  the  end  of  the  named  external  file. 

In  normal  circumstances,  when  an  external  file  is  opened,  an  index  is  set  that  points  to  the  beginning  of 
the  file.  If  the  APPEND  attribute  is  present  for  a  sequential  or  text  file,  data  transfer  commences  at  the 
end  of  the  file.  For  a  direct  access  file,  the  value  of  the  index  is  set  to  one  more  than  the  number  of 
records  in  the  external  file. 

The  APPEND  attribute  is  not  applicable  to  terminal  devices 
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F  8.2.8  The  FORM  Parameter  Attribute  -  Blocking 

This  attribute  has  two  alternative  forms: 

BLOCKING 

or 

NON_BLOCKING 

This  attribute  specifies  the  I/O  system  behavior  when  a  request  for  data  transfer  cannot  be  fulfilled  at 
that  moment  This  stoppage  may  be  due  to  the  unavailability  of  data,  or  to  the  unavailability  of  the 
external  file  device. 

F  8.2.8.1  Blocking 

If  the  blocking  attribute  is  set,  the  task  waits  until  the  data  transfer  is  complete,  and  all  other  tasks  are 
suspended  (or  blocked).  The  system  is  busy  waiting. 

The  default  for  this  attribute  depends  on  the  actual  program.  It  is  BLOCKING  for  programs  without  any 
task  declarations  and  it  is  NON_BLOCKINC  for  a  program  conuining  tasks. 

F  8.2.8.2  Non-Blocking 

If  the  non -blocking  attribute  is  set,  the  task  that  ordered  the  data  transfer  is  suspended  and  the  other 
tasks  can  execute.  The  suspended  task  is  rescheduled  and  kept  in  a  ready  state  together  with  other  tasks 
in  a  ready  state  at  the  same  priority  level 

When  the  suspended  task  is  scheduled  again,  the  data  transfer  request  is  reactivated.  If  ready,  the  transfer 
is  activated;  otherwise  the  rescheduling  is  repeated.  Control  r^tunu  to  your  program  after  the  data 
transfer  is  complete. 

F  8.2.9  The  FORM  Parameter  -  Terminal  Input 

The  terminal  input  attribute  takes  one  of  two  alternative  forms: 

TERMINAL_INPUT  ■>  LINES, 

TERMINAL_INPUT  «>  CHARACTERS. 

Terminal  input  is  normally  processed  in  units  of  one  line  at  a  time,  where  a  line  is  delimited  by  a  special 
character.  A  process  attempting  to  read  from  the  terminal  as  an  external  file  is  suspended  until  a 
complete  line  has  been  typed.  At  that  time,  the  outstanding  read  call  (and  possibly  also  later  calls)  is 
satisfied. 

The  LINES  option  specifies  line-at-a-time  dau  transfer,  which  is  the  default  case. 

The  CHARACTERS  option  means  that  data  transfers  character  by  character,  and  so  a  complete  line  does  not 
have  to  be  entered  before  the  read  request  can  be  satisfied.  For  this  option,  the  BUFFER^SIZE  must  be 
zero. 

The  TERMINAL  INPUT  attribute  is  only  applicable  to  terminal  devices  other  than  the  one  pre-connected 
to  STANDARD  INPUT  and  STANDARD  OUTPUT. 
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F.9  The  HP  Ada  Compilation  System  and  HP-UX  Signals 

The  HP  Ada  run  time  in  the  HP-9000  Series  300  uses  HP-UX  signals  to  implement  the  following  features 
of  the  Ada  language: 

•  Ada  exception  handling 

•  Ada  task  management 

•  Ada  delay  timing 


F  9.1  HP-UX  Signals  Reserved  by  the  Ada  Run  Time 

The  HP-UX  signals  reserved  by  the  Ada  run  time  are: 

•  SICFPC 

•  SIGILL 

•  SICBUS 

•  SZGSECV 

•  SIGEMT 

•  SIGALRM 

•  SIGVTALRM 


iWARNING 


The  signak  reserved  for  use  by  the  HP  Ada  run  thne  may  be  used  in  your 
Ada  programs  only  with  extreme  cautioa  If  you  attempt  to  generate, 
catch,  or  ignore  these  signals,  the  Ada  program  can  produce  unpredictable 
results. 


F  9.2  HP-UX  Signals  Used  for  Hp  Ada  Exception  Handling 

Signals  are  used  to  raise  some  HP  Ada  exceptions.  The  HP  Ada  run  time’s  handlen  for  operating  system 
signals  are  set  during  the  elaboration  of  the  HP  Ada  run  time.  Defining  a  new  handler  for  any  of  these 
signals  destroys  the  normal  exception  handling  mechanism  of  Ada  and  may  result  in  erroneous  run-time 
execution. 

The  following  signals  are  used  for  exception  handling: 

SIGILL,  SIGFPE,  SIGBUS,  SICSEGV,  SIGEMT 


F  9.3  HP-UX  Signals  Used  for  Ada  Task  Management 

The  HP-UX  alarm  facility  is  used  by  the  Ada  run  time  for  task  management  Ulien  the  Ada  program 
contains  tasks,  the  HP-UX  alarm  signal  SIGVTALRM  is  used  to  implement  time  slicing.  In  time  slicing,  the 
Ada  run  time  allocates  the  available  processor  time  among  concurrent  taski  If  the  Ada  program  does  not 
contain  tasks,  it  is  a  sequential  program.  The  Ada  run  time  in  sequential  programs  does  not  use  the 
HP-UX  signal  SIGVTALARM. 
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Be  careful  if  you  use  external  routines  that  may  use  HP-UX  signals  reserved  by  the  HP  Ada  run  time.  If 
HP-UX  alarm  signals  are  caught,  generated,  or  ignored,  then  interaction  between  external  subprograms 
and  Ada  tasking  can  produce  unpredictable  program  behavior.  If  you  redefine  a  handler  for 
alarm-related  signals,  unexpected  results  may  occur.  For  more  information,  see  the  section  "Potential 
Problems  Using  Interfaced  Subprograms"  (Section  F  1. 1.6X 


F  9.4  HP-UX  Signals  Used  for  Ada  Delay  Timing 

The  HP-UX  alarm  signal  SICALRH  is  used  by  the  run  time  when  the  Ada  program  contains  DELAY 
statements  to  wait  for  the  delays  to  expire. 

If  HP-UX  alarm  signals  are  used,  interaction  between  external  subprograms  and  Ada  DELAY  statement 
execution  can  produce  unpredictable  program  behavior.  If  you  redefine  a  handler  for  alarm-related 
signals,  unexpected  results  may  occur.  See  the  section  "Potential  Problems  Using  Interfaced  Subprograms" 
(Section  F  1 4. 7). 


F  9.5  Protecting  interfaced  Code  from  Ada’s  Asynchronous  Signals 

The  two  signals  mentioned  above  (SIGALRM  and  SICVTALRM)  occur  asynchronously.  Because  of  this,  they 
may  occur  while  your  code  is  executing  an  interfaced  subprogram.  For  details  on  protecting  your 
interfaced  subprogram  from  adverse  effects  caused  by  these  signals,  tee  the  section  in  the  HP  Ada  User’s 
Guide  on  "Interfaced  Subprograms  and  Ada’s  Use  of  Signals." 


F  9.6  HP-UX  Signals  Used  in  Ada  Program  Termination 

Some  HP-UX  signals  cause  the  HP-UX  process  (your  Ada  pro^m)  to  terminate.  These  signals  are 
discussed  in  this  section.  Some  of  these  signals  produce  different  program  behavior  from  others  at 
termination  time.  This  behavior  it  described  below. 


The  following  signals  are  caught  by  the  HP  Ada  run-time  system,  which  resets  the  terminal  to  the 
terminal  configuration  that  was  in  effect  before  the  program  is  executed,  cleans  up  any  locks  that  might 
be  left  by  an  abnormal  termination,  and  terminates  the  Ada  program. 


SICHUPv 

SICIOT 

SICTERM* 

SIGPROF 


SIGINT* 

SIGKILL 

SICUSR1* 

SICIO 


SICQUIT* 

SIGSYS 

SIGUSR2* 

SICDIL 


SICTRAP 

SIGPIPE* 

SIGPWR 

SICWINDOW 


Signals  marked  with  an  *  are  caught  by  the  Ada  run-time  system  only  if  they  are  not  ignored  at  the  time 
the  Ada  program  is  executed.  (See  (signal (2)  in  the  HP-UX  Reference.) 

Your  use  of  signals  to  terminate  an  Ada  program  affects  the  use  of  Ada  I/O.  No  cleanup  of  Ada  I/O  is 
performed  by  the  Ada  run  time  if  a  signal  is  used  to  exit  the  program  unless  you  do  the  cleanup  prior  to 
sending  such  a  signal 


F  9.7  HP-UX  Exit  Status  and  Signals  in  Ada 

If  an  unexpected  signal  is  received,  the  HP  Ada  run  time  terminates  the  Ada  program  with  a  non -zero 
HP-UX  exit  status.  However,  the  :un  time  does  not,  in  general,  terminate  the  Ada  program  in  a  manner 
that  follows  HP-UX  conventions.  The  conventional  HP-UX  method  of  program  termination  is  to 
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indicate  the  reason  for  termination  (if  caused  by  a  signal)  in  the  exit  statua  The  HPoUX  convention  is 
adhered  to  only  for  the  signals  listed  in  Section  F  9. 6  (which  cause  termination).  For  other  signals,  the 
exit  status  is  non-zero  but  does  not  indicate  that  the  cause  of  termination  was  a  signal 

F  9.8  Programming  in  Ada  With  HP-UX  Signals 

If  you  intend  to  utilize  signals  in  interfaced  subprograms,  refer  to  the  section  on  "Potential  Problems  Using 
Interfaced  Subprograms"  (Section  F  1 4. 7).  This  version  of  the  product  does  not  support  the  association  of 
an  HP-UX  signal  such  as  SIGINT  with  an  Ada  procedure  or  a  task  entry.  The  signal  must  be  handled 
inside  an  external  subprogram.  The  same  cautions  apply  for  this  external  subprogram  as  for  any  external 
interfaced  subprogram  that  might  be  interrupted  by  an  unexpected  signal. 

Table  F-1 0  provides  a  summary  of  HP-UX  Signals. 
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Tabic  F-10.  Summary  of  HP-UX  Signals  and  HP  Ada/300 


Reserved 

By 

Ada 


HP-UX  Signal 
Number 
and  Name 

Description 

(01)  SICHUP 

hangup 

(02)  SICINT 

interrupt 

(03)  SICQUIT 

quit 

(04)  SIGILL 

illegal  instruction 

(05)  SIGTRAP 

trace  trap 

(06)  SIGIOT 

sof  tware  -generated 

(07)  SIGEMT 

software-generated 

(08)  SIGFPE 

floating  point  exception 

(09)  SICKILL 

kill 

(10)  SICBUS 

bus  error 

(11)  SICSECV 

segmentation  violation 

(12)  SICSYS 

bad  arg  to  system  call 

(13)  SICPIPE 

broken  pipe 

(14)  SIGALRN 

alarm  clock 

(15)  SICTERM 

software  termination  signal 

(16)  SICUSR1 

user  defined  signal  1 

(17)  SICUSR2 

user  defined  signal  2 

(18)  SICCLD 

death  of  a  child  process 

(19)  SIGPWR 

power  fail 

(20)  SIGVTALRM 

virtual  timer  alarm 

(21)  SIGPROF 

profiling  timer  alarm 

(22)  SIGIO.SICDIL 

asychronoui  I/O  signal 

(23)  SIGWINOOW 

window  or  mouse  signal 

Program 

Terminates 

Caught 

If 

Ignored 

yes 

no 

yes 

no 

yes 

no 

no 

yes 

yes 

yes 

yes 

yes 

no 

yes 

no 

yes 

yes 

yes 

no 

yes 

no 

yet 

yes 

yes 

yes 

no 

no 

yes 

yes 

no 

yes 

no 

yes 

no 

no 

yet 

yes 

yes 

no 

yes 

yet 

yes 

yes 

yes 

yes 

yes 
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F  10.  Predefined  Language  Attributes 

The  predefined  language  attributes  are  implemented  as  defined  in  the  Reference  Manual  for  the  Ada 
Programming  Language,  Appendix  A,  with  the  following  exception. 

P'ST0RACE_SI2E 

When  applied  to  an  access  type  or  subtype  of  an  access  type  the  compiler  produces  one  of  two  responses: 

•  If  there  is  no  length  clause,  the  compiler  issues  the  warning: 

Th«  prefix  of  the  attribute  STORACCjSIZC  it  an  access  type  which  has  no  length 
clausa.  The  value  returned  by  STORACCJSIZE  is  always  0. 

•  If  a  length  clause  is  specified,  the  compiler  issues  the  error 
Length  clauses  are  not  currently  implefflented. 
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F  11.  Predefined  Language  Pragmat 

The  predefined  language  pragmas  are  implemented  as  defined  in  the  Reference  Manual  for  the  Ada 
Progreunming  Language,  Appendix  B,  with  the  following  exceptions  (see  also  'Implementation -Dependent 
Pragmas”  in  this  appendix^ 

Use  of  the  predefined  language  pragmat 

CONTROLLED 

MEMORY  SIZE 

OPTIMIZE 

PACK 

SHARED 

STORAGE  UNIT 

SYSTEM_^NAME 

is  either  ignored  without  comment  (the  pragma  has  no  effect  as  required  by  the  Reference  Manual  for  the 
Ada  Programming  Language)  or  elicits  this  warning  from  the  compiler 

This  pragma  ia  not  currently  aupportad  by  the  implamantation. 
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F  12.  Data  Type  Ranges,  Alignment,  and  Layout 


Table  F- 12 


Tables  F-1 1  and  F-12  show  data  type  nnges  and  alignment  Information  on  layout 
memory  is  contained  in  Section  113. 

F  12.1  Data  Type  Ranges 


SHOR 


Table  F*  1 1  shows  data  type  ranges. 


SHOR 

INTE« 

ENUh 
(<•  12 


Ada  Type 


SHORT  SHORT  INTEGER 


Table  F'lL  Rangee 


-128..  127 


Range 


ENU^ 
(>  121 


FIXE! 


FLOA 


TASK 


SHORT  INTEGER 


INTEGER 


ENUMERATION 


BOOLEAN 


CHARACTER 


LONG_FLOAT 


-32768..  32767 


-2_147_483_648..  2_147_483_647 


32768  elements  maximum.  0..  127  (for  <■  128  < 
0..  32767  (for  >  128  elements) 


FALSE.TRUE  (2#0000_0000d', 


ASCn.NUL..ASCU.DEb(0..  127) 


-2#i.iii_iiii_iin_nii_iin_ini4 

..  iri.iii_iiii_iiii_iiii_iiii_iii: 

(that  it,-3.402823E+38..+3.402823E-*-38,  apprc 


-2#1. 1 1 1 1_1 1 1 1_1 1 1 1_1 1 1 1_1 1 1  i_n  1 1 

llll_llll_llll_llll_llll_llll<rE+l( 

..2#i.iiii_iiii_iiii_iiu_ini_iin 

1111_1111_1111_1111_1111_11114^+1( 
(that  is,  -1.7976931 3486231  SEf308  .. 

<•■1. 797693 1 3486231 5E<«>308,  approximai 
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F  12.3  Layout  of  Data  Objects  In  Memory 


1.  Integer  Types 

SHORT^SHORT^INTECER,  SHORT^INTECER.  end  IMTECER  are  respectively  allocated  8  bits,  16  bits,  and 
32  bita  For  a  user*defined  integer  type,  the  representation  chosen  is  the  smallest  of  the  predefined 
integer  types  whose  range  includes  the  range  of  the  declared  type. 

2.  Enumeration  Types  Other  Than  Boolean 

A  value  of  an  enumeration  type  without  a  represenUtion  clause  {LRM,  Section  1 3. 3)  is  represented  by 
the  non-negative  integer  value  corresponding  to  its  position  in  the  type  definition  (positioiu  are 
numbered  from  zero).  The  values  of  enumeration  types  are  signed  (but  never  negative).  Thus,  only 
enumeration  types  defining  up  to  128  elements  are  represented  in  a  byte;  others  are  represented  in  16 
bits  (a  half  word). 

3.  The  Type  CHARACTER 

The  type  CHARACTER  is  represented  u  a  user-defined  enumeration  type  of  less  than  1 29  elements 
(integer  range  0  through  1 27),  corresponding  to  ASCI  1 .  NUL  through  ASCI  I .  DEL 

4.  The  Type  BOOLEAN 

The  values  FALSE  and  TRUE  are  represented  as  the  8-bit  value  0  and  25S  (that  is,  2^111 1 1 1 1 1#) 

zero  and  one  in  a  byte.  The  value  of  BOOLEAN 'POS  (TRUE)  it  one  and  the  value  of 
BOOLEAN'POS  (FALSE)  is  zero.  The  result  type  it  univeraal  integer  for  the  POS  attribute. 

5.  Fixed  Point  Types 

A  value  of  a  fixed  point  type  is  managed  by  the  compiler  as  the  value  of  signedjnantieaa  *  enalL 
Signed^^mantisea  it  a  signed  integer.  Small  it  the  lau-gest  power  of  two  that  is  not  greater  than  the 
delta  of  the  fixed  accuracy  definition.  Small  it  a  compile-time  constant,  to  eignadjnantiaea  is  the 
only  portion  that  needs  memory  space  at  run  time.  Thus,  fixed  point  types  are  mapp^  into  one  of  the 
three  predefined  integer  typea 

6.  Floating  Point  Types 

A  floating  point  value  of  type  FLOAT  is  represented  in  normalized  32-bit  IEEE  format: 
bit  0:  sign  (most  significant  bit) 
bits  1  to  8:  exponent 
bits  9  to  31:  mantissa 

A  floating  point  value  of  type  LONC_FLOAT  is  represented  in  normalized  64-bit  IEEE  format 
bit  0:  sign  (most  significant  bit) 
bits  1  to  11:  exponent 
bits  12  to  63:  mantissa 
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7.  Array  Types 

•  Genera}  case:  array  elements  in  Ada  are  allocated  cantifQOusly  in  memory  and  stored  by  rowa  This 
is  called  row>major  order,  with  the  last  subscript  varyint  most  rapidly,  the  next  to  last  varying  next 
most  rapidly,  and  the  first  subscript  varying  least  rapidly.  The  size  of  an  array  is  the  product  of  the 
number  of  its  elements  and  its  element  size. 

•  Special  case:  elements  with  an  odd  number  of  bytes  are  padded  to  start  at  a  word  boundary.  An 
example  of  this  is  an  array  with  an  element  type  that  is  a  record.  The  record  contains  two 
components,  of  type  INTEGER  and  BOOLEAN,  respectively.  Instead  of  allocating  these  record  type 
elements  contiguously,  all  elements  are  extendi  with  a  null  byte  to  make  them  even  sized. 
Therefore,  the  array  size  (in  bytes)  is  the  product  of  the  number  of  elements  and  the  number 
represented  by  one  greater  than  the  element  size  (in  bytes). 

8.  Record  Types 

Record  components  are  allocated  contiguously  in  memory  with  holes  inserted  between  components  to 
satisfy  their  alignment  constraint!  The  alignment  constraint  of  a  record  is  the  strongest  alignment 
constraint  of  any  of  its  component! 

Implicit  components  are  components  created  by  rite  compihy  within  a  record.  They  can  be  used  to  hold 
the  record  size,  array  or  record  descriptors,  or  variant  indexe!  The  implicit  component  for  the  record 
size  is,  in  general,  placed  at  the  beginning  of  the  record. 

Ada  semantics  do  not  require  a  particular  ordering  of  record  component!  Record  components  can  be 
rearranged  by  the  compiler  to  take  into  account  alignment  constraint!  Record  components  can  be 
arranged  in  an  order  other  than  the  declarative  order. 

For  dynamic  components,  a  dope  (pointer)  is  created  where  thft  component  would  normally  have  been 
placed,  and  the  component  itself  is  allocated  at  the  end  of  the  record.  The  dope  contains  the  offset 
from  the  start  of  the  record  to  the  actual  component. 

If  the  size  of  a  component  depends  upon  a  discrimdnanx,  the  maximum  size  is  allocated. 

For  a  record  type  with  variant  parts,  the  common  part  and  each  variant  part  are  laid  out  in  the  tame 
way  as  detcrilMid  above,  with  the  exception  that  dynamic  components  are  laid  out  at  the  end  of  the 
entire  record,  not  at  the  end  of  a  specific  variant  part.  Variant  parts  are  overlaid  when  possible  and 
holes  of  previously  laid  out  variant  parts  are  used  whenever  possible. 

9.  Parameters 

When  passing  parameters  by  value  within  HP  Ada,  byte-aligned  objects  are  considered  at  word  aligned 
and  right -justified  and  odd-byte-sized  parameters  are  pasted  in  word-sized  container!  This  ensures 
that  the  stack  pointer  remains  divisible  by  4.  (For  information  on  passing  parameters  to  external 
interfaced  subprograms  written  in  other  languages,  refer  to  Section  F  14. 1  of  this  appendix.) 
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It  is  impossible  to  give  exact  numbers  for  most  of  the  limits  given  here. 
The  various  language  features  may  interact  in  complex  ways  to  lower  the 
following  limits.  The  numbers  represent  “hard"  limits  in  simple  program 
fragments  devoid  of  other  Ada  features. 


Limit  Description 

255  Maximum  number  of  characters  in  a  source  line. 

253  Maximum  number  of  characters  in  a  string  literal 

255  Maximum  number  of  characters  in  an  enumeration  type  element 

32767  In  an  enumeration  type,  the  sum  of  the  lengths  of  the  IMAGE  attributes  of  all 
elements  in  the  type,  plus  the  number  of  elements  in  the  type,  must  not  exceed  this 
value. 

2047  Maximum  number  of  actual  compilation  units  in  a  library. 

32767  Maximum  number  of  enumeration  elements  in  a  single  enumeration  type  (this  limit 
is  further  constrained  by  the  maximum  number  of  characters  for  all  enumeration 
literals  of  the  type). 

2047  Maximum  number  of  "created"  units  in  a  single  compilation. 

2**  31-1  Maximum  number  of  bits  in  any  size  computation. 

2048  Links  in  a  library. 

2048  Libraries  in  the  INSTALLATION  family  (250  of  which  are  reserved). 

2047  Libraries  in  either  the  PUBLIC  or  a  user  defined  family.  (For  more  information,  see 
the  Ada  User's  Guide,  which  discusses  families  of  Ada  libraries  and  the  supported 
utilities  (tools)  to  manage  them). 

Maximum  number  of  tasks  is  limited  only  by  heap  size. 

-  The  offset  of  a  record  component  has  to  be  representable  in  16-bit  integer. 


B-52 


ImplemenUtion-Dependent  Characteristics 


The  following  items  are  limited  only  by  overflow  of  internal  tables  (AIL  or  HLST  tables).  All  internal 
data  structures  of  the  compiler  which  previously  placed  fixed  limits  are  now  dynamically  created. 

~  Maximum  number  of  identifiers  in  a  unit  An  identifier  includes  enumerated  type 
identifiers,  record  field  definitions,  and  (generic)  unit  parameter  definitions. 

-  Maximum  "structure”  depth.  Structure  includes  the  following:  nested  blocks, 
compound  statements,  aggregate  associations,  parameter  associations,  subexpressions. 

Maximum  array  dimensions.  Set  to  Maximum  structure  depth/ 1 0.* 

~  Maximum  number  of  discriminants  in  a  record  constraint* 

-  Maximum  number  of  associations  in  a  record  aggregate.* 

**  Maximum  number  of  parameters  in  a  subprogram  definition.* 

Maximum  expression  depth.* 

-  Maximum  number  of  nested  frames.  Library-level  unit  counts  as  a  frame. 

-  Maximum  number  of  overloads  per  compilation  unit 

-  Maximum  number  of  overloads  per  identifier. 

*  A  limit  on  the  size  of  tables  used  in  overloading  resolution  can  potentially  lower  this 
figure.  This  limit  it  set  at  500.  It  reflects  the  number  of  possible  interpretations  of  names 
in  any  tingle  construct  under  analysis  by  the  compiler  (procedure  call,  assignment 
statement,  etc.X 


The  following  limits  apply  to  the  Ada  development  environment  (ada.umgr,  ada.fmgr,  Ada  tools). 

Limit  Description 

200  The  number  of  characters  in  the  actual  rooted  path  of  an  Ada  program  LIBRARY  or 
FAMI LY  of  librariea 

200  The  number  of  characters  in  the  string  (possibly  after  expansion  by  an  HP-UX  shell) 
specifying  the  name  of  an  Ada  program  LIBRARY  or  FAMILY  of  libraries.  This  limit 
applies  to  strings  (pathname  expressions)  specified  for  a  LIBRARY  or  FAMILY  that  you 
submit  to  tools  such  as  ada.mkiib  or  ada.umgr. 

512  Maximum  length  of  an  input  line  for  the  tools  ada.fmgr  and  ada.umgr. 
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F  14.  Calling  External  Subprograms  From  Ada 

In  the  HP  implementation  of  Ada,  subprogram  parameters  of  external  interfaced  subprograms  are  passed 
on  the  stack  in  reverse  order  of  their  declaration.  The  first  parameter  appears  at  the  top  of  the  stack. 
This  same  ordering  is  used  by  HP  for  other  language  products  on  the  HP  9000  Series  300  family  of 
computers.  The  languages  described  in  Section  14  of  this  Appendix  are  HP  implementations  of  680X0 
Assembler,  C,  FORTRAN  77,  and  Pascal  on  the  HP-UX  Series  300  systenu. 

In  some  cases,  the  interface  requires  not  only  the  parameters  but  additional  information  to  be  pushed  on 
the  stack  as  weU.  This  information  may  include  a  parameter  count,  a  return  result  pointer,  or  other 
bookkeeping  information.  When  you  specify  the  interfaced  language  name,  that  name  is  used  to  select 
the  correct  calling  conventions  for  supported  languages.  Then,  subprograms  written  in  HP  C, 
HP  FORTRAN  77,  and  HP  Pascal  interface  correctly  with  the  HP  Ada  subprogram  caller. 

Section  F  14  contains  detailed  information  about  calling  subprograms  written  in  these  languages.  If  the 
subprogram  is  written  in  a  language  from  another  vendor,  you  must  follow  the  standard  calling 
conventions. 

In  the  HP  Ada  implementation  of  external  subprogram  interfaces,  the  three  Ada  parameter  passing  modes 
(IN,  OUT,  IN  OUT)  are  supported,  with  some  limitations  as  noted  below.  Scalar  and  access  parameters  of 
mode  IN  are  passed  by  value.  All  other  parameters  of  mode  IN  are  passed  by  reference.  Parameters  of 
mode  OUT  or  IN  OUT  are  always  passed  by  reference.  (See  Table  F- 1 3  and  Figure  F- 1. ) 


Tabic  F-13.  Ada  Types  and  Parameter  Passing  Modes 


Ada  Type 

ModePaaead 
By  Value 

•  Mode  Passed 

By  Reference 

SCALAR, 

ACCESS 

IN 

OUT.  IN  OUT 

All  others  except 

TASK,  private,  and 
FIXED  POINT 
(REAL) 

IN,  OUT,  IN  OUT 

TASK,  private,  and 
FIXED  POINT 
(REAL) 

(not  passed) 

(not  passed) 

The  values  of  the  following  types  cannot  be  passed  u  parameten  to  an  external  subprogram: 

Task  types  (LRM  Section  9. 1,  9. 2), 

Private  types  (LRAf  Section  7. 4), 

Fixed  point  types  (LRAf  Section  3. 5. 9,  3. 5. 1 0). 

A  composite  type  (an  array  or  record  type)  is  always  passed  by  reference  (as  noted  above).  A  component  of 
a  composite  type  is  passed  according  to  its  type  classification  (scalar,  access,  or  composite). 

Only  scalar  types  (enumeration,  character,  boolean,  integer,  or  real)  or  access  types  are  allowed  for  the 
result  returned  by  an  external  function  subprogram. 
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NOTE 


There  are  no  checks  for  consistency  between  the  subprogram  parameters  (as 
declared  in  Ada)  and  the  corresponding  external  subprogram  parameters. 
Because  external  subprograms  have  no  notion  of  Ada’s  parameter  modes, 
parameters  passed  by  reference  are  not  protected  from  modification  by  an 
external  subprogram.  Even  if  the  parameter  is  declared  to  be  only  of  mode 
IN  (and  not  OUT  or  IN  OUT)  but  is  passed  by  reference  (that  ia,  an  array  or 
record  type),  the  value  of  the  Ada  actual  parameter  can  still  be  modified 

The  possibility  that  the  parameter’s  actual  value  will  be  modified  by  an 
interfaced  external  subprogram  exists  when  that  parameter  is  not  pasted  by 
value.  Objects  whose  attribute  'ADDRESS  is  passed  as  a  parameter  and 
parameters  passed  by  reference  are  not  protected  from  alteration  and  are 
subject  to  modification  by  the  external  subprogram.  In  addition,  such 
objects  will  have  no  run-time  checks  performed  on  their  values  upon 
return  from  interfaced  external  subprograms. 

Erroneous  results  may  occur  if  the  parameter  values  are  altered  in  some 
way  that  violates  Ada  constraints  for  the  actual  Ada  parameter.  The 
responsibility  to  ensure  that  values  are  not  modified  in  external  interfaced 
subprogranu  in  such  a  manner  as  to  subvert  the  strong  type  and  range 
checking  enforced  by  the  Ada  language  is  yours. 


CAUTION 


Be  very  careful  to  establish  the  exact  nature  of  the  types  of  parameten  to 
be  passed.  The  bit  representations  of  these  types  can  be  different  between 
this  implementation  of  Ada  and  other  languages,  or  between  different 
implementations  of  the  same  language.  For  example,  between  different 
releases  of  HP  Ada,  the  redefinition  of  the  size  of  the  predefined  standard 
type  INTEGER  may  have  changed,  increasing  from  a  16-bit  storage  size  to  a 
32-bit  storage  size.  Stacked  values  must  occupy  equal  space  in  the  two 
interfaced  languagea  When  passing  record  types,  pay  particular  attention 
to  the  internal  organization  of  the  elements  of  a  record  because  Ada 
semantics  do  not  guarantee  a  particular  order  of  componenta  Moreover, 
Ada  compilers  are  free  to  rearrange  or  add  components  within  a  record. 
(See  Section  F  11  on  data  type  layout  for  more  information.) 


B-55 


Implemenution -Dependent  Characteristics 


F  14.1  General  Considerations  In  Passing  Ada  Types 

Section  F  1 4. 1  discusses  each  data  type  in  general  terms.  Sections  F  1 4. 2  through  F  1 4.  5  describe  the 
details  of  interfacing  your  Ada  programs  with  eaternal  subprograms  written  in  HP  C,  HP  FORTRAN  77, 
HP  Pascal  Section  F  1 4. 6  provides  summary  Ubles. 

The  Ada  types  are  described  in  the  following  order 

•  Scalar 

•  Integer 

■  Enumeration 

■  Boolean 

■  Character 

•  Real 

•  Access 

•  Array 

•  Record 

•  Task 

•  Private 
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F  14.1.1  Scalar  Types 

This  section  describes  general  considerations  when  you  are  passing  scalar  types  between  Ada  programs  and 
subprograms  written  in  a  different  HP  language.  The  class  scalar  typts  includes  integer,  real,  and 
enumeration  typea  Because  character  and  boolean  types  are  predefined  Ada  enumeration  types,  they  are 
also  scalar  typea 

Scalar  type  parameters  of  mode  IN  are  passed  by  value.  Scalar  type  parameters  of  mode  IN  OUT  or  OUT 
are  passed  by  reference. 


F  14.1.1.1  Integer  Types 

In  HP  Ada,  all  integers  are  represented  in  two’s  complement  form.  SHORT_SHORT_INTECERS  are 
represented  as  8-bit  numbers,  SHORT_INTECERS  are  represented  as  16-bit  numbers,  and  INTEGERS  are 
represented  as  32-bit  numbera  ~ 

All  integer  types  can  be  passed  to  interfaced  subprograma  When  an  integer  is  used  as  a  parameter  for  an 
interfaced  subprogram,  the  call  may  be  made  either  by  reference  or  by  value.  For  a  call  by  reference,  the 
value  of  the  actual  integer  parameter  is  not  copied  or  modified,  but  a  32-bit  address  pointer  is  pushed  on 
the  stack.  For  a  call  by  value,  a  copy  of  the  actual  integer  parameter  value  is  pushed  on  the  stack,  with 
sign  extension  as  necessary  to  satisfy  the  requirements  of  the  external  subprogram.  See  Sections 
F  14. 2. 1. 1,  F  14. 3. 1. 1,  F  14. 4. 1. 1,  and  F  14.5. 1. 1  for  details  specific  to  interfaced  subprograms  written 
in  different  languagea 

Integer  types  may  be  returned  as  function  results  from  external  interfaced  subprograms. 


F  14.1.1.2  Enumeration  Types 

Values  of  an  enumeration  type  {LRM  3. 5. 1)  without  an  enumeration  representation  clause  UJIM  13.3) 
have  an  internal  represenution  of  the  value’s  position  in  the  list  of  enumeration  literals  definin,;  the  type. 
These  values  are  non -negative.  The  first  literal  in  the  list  corresponds  to  an  integer  value  of  zero. 

There  can  be  no  more  than  32768  elements  in  an  enumeration  type  and,  because  the  program 
representation  of  the  position  number  of  an  element  starts  at  zero,  the  maximum  value  is  32767. 

Values  of  enumeration  types  with  less  than  128  elements  are  represented  as  a  non -negative  integer  in 
eight  bits,  whereas  values  of  other  enumeration  types  are  represented  as  a  non -negative  integer  in  16  bits. 
When  passed  by  value,  the  copy  of  the  integer  is  treated  as  if  it  were  an  unsigned  integer,  with  any 
necessary  extension  up  to  32  bits  to  satisfy  the  requirements  of  the  external  subprogram.  Sm  Sections 
F  1 4. 11. 2,  F  1 4. 3. 1. 2,  F  1 4. 4. 1. 2,  and  F  1 4. 5. 1. 2  for  specific  detaila 

Enumeration  types  may  be  returned  as  function  results  from  external  interfaced  subprograms. 


F  14.1.1.3  Boolean  Types 

The  values  of  the  predefined  enumeration  type  BOOLEAN  are  represented  in  HP  Ada  as  8 -bit  valuea  The 
boolean  value  FALSE  is  represented  by  the  8-bit  value  zero,  and  the  boolean  value  TRUE  is  represented  by 

the  8 -bit  value  255  (#1 1 1 1 _ 1111#).  This  is  not  the  same  as  other  enumeration  types  that  occupy  eight 

bits  in  Ada,  where  the  position  in  the  enumeration  list  at  declaration  defines  the  internal  representation 
for  the  element 
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When  a  boolean  is  passed  by  reference,  its  value  it  not  copied,  but  a  32-bit  address  pointer  is  pushed  on 
the  stack.  When  a  boolean  is  passed  by  value,  a  copy  is  pushed  on  the  stack.  The  Ada  boolean  value 
occupies  one  byte,  and  it  is  up  to  you  to  ensure  that  the  boolean  is  in  a  correct  format  for  the  external 
subprogram. 

Boolean  types  may  be  returned  as  function  results  from  external  interfaced  subprograms  with  caution  as 
noted  above. 

See  Sections  F  14.11.3,  F14. 3. 1. 3,  F14. 4. 1.3,  and  F14.  S.  1.3  for  information  about  interfaced 
subprograms  written  in  Assembler,  HP  C,  HP  FORTRAN  77,  and  HP  Pascal 


F  14.1.1.4  Character  Types 

The  values  of  the  predefined  enumeration  type  CHARACTER  are  represented  as  8 -bit  values  in  a  range  0 
through  127. 

character  types  may  be  returned  as  function  results  from  external  subprograms. 


F  14.1.1.5  Real  Types 

Ada  fixed  point  types  and  Ada  floating  point  types  are  discussed  in  the  following  subsections. 

Fixed  Point  Reai  Types 

Ada  fixed  point  types  (LRM  3.  S.  9,  3. 5. 1 0)  are  not  supported  as  parameten  or  as  results  of  external 
subprogram! 

Fixed  point  types  cannot  be  returned  u  function  results  from  external  subprograms. 

Floating  Point  Real  Types 

Floating  point  values  (LRM  Sections  3.5.7  sind  3.5.8)  in  the  HP  implementation  of  Ada  are  of  32  bits 
(FLOAT)  or  64  bits  (LONC_rLOAT).  These  two  types  conform  to  the  conventions  defined  in  the  document 
"A  Proposed  Standard  for  Binary  Floating  Point  Arithmetic",  I££E  P754,  draft  10.  (X 

When  passed  by  reference,  a  3  2 -bit  address  pointer  to  the  object  is  pushed  on  the  stack.  When  passed  by 
value,  a  copy  is  pushed  on  the  stack,  possibly  with  extension  to  64  bits  according  to  the  external 
subprogram  interfacing  convention!  See  Sections  F  1 4. 1  ].  5,  F  1 4. 3. 1. 5,  F  1 4. 4. 1. 5,  and  F  1 4. 5. 1. 5  for 
details  specific  to  interfaced  subprograms  written  in  different  language! 

Floating  point  types  may  be  returned  as  function  results  from  external  interfaced  subprograms,  with  some 
restriction! 
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F  14.1.2  Access  Types 

Values  of  an  access  type  (LAM,  Section  3.8)  have  an  internal  representation  as  the  3  2 -bit  address  of  the 

underlying  designated  object  (such  as  an  object _ address  stored  in  an  object _ address _ location).  An 

access  type’s  value  is  an  address  pointer  to  the  object.  Therefore,  when  an  access  type  is  passed  by  value,  a 

copy  of  this  32-bit  object _ address  is  pushed  on  the  stack.  If  the  type  is  passed  by  reference,  however,  the 

32 -bit  address  pointer  to  the  object _ address _ location  is  pushed  on  the  stack.  This  is  effectively  a 

double  indirect  address  to  the  designated  object.  See  Figure  F-1. 


Figure  F-1.  Passing  Access  Types  to  Interfaced  Subprograms 


Access  types  may  be  returned  as  function  results  from  external  interfaced  subprograms. 

Ada  access  types  are  pointers  to  Ada  objects.  Ada  access  types  to  simple  objects  (scalar  type  or  other  access 
type  objects)  are  actually  pointers  to  the  designated  object.  Ada  access  type  values  pointing  to  composite 
types  (record  or  array  types)  are  pointers  to  Ada  descriptors  for  that  object,  rather  than  pointers  to  the 
actual  object. 


CAUTION 


The  descriptors  used  by  Ada  are  nor  identical  to  descriptors  used  by  other 
languages.  Therefore,  an  Ada  access  type  value  that  points  to  a  composite 
type  may  have  no  meaning  or  may  ha'  e  a  different  meaning  when  passed  as 
a  parameter  to  a  subprogram  written  in  another  language. 
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F  14.1.3  Array  Types 

In  the  HP  implementation  of  Ada,  arrays  (LAAf,  Section  3. 6)  are  always  passed  by  reference.  The  value 
pushed  on  the  stack  is  the  address  of  the  first  element  of  the  array.  When  an  array  is  passed  as  a 
parameter  to  an  external  interfaced  subprogram,  the  usual  checks  on  the  consistency  of  array  bounds 
between  the  calling  program  and  the  called  subprogram  are  not  enforced.  You  are  responsible  for 
ensuring  that  the  external  interfaced  subprogram  keeps  within  the  proper  array  bounds. 

Values  of  the  predefined  type  STRING  {LRM,  Section  3.6.3)  are  a  special  case  of  arrays  and  are  passed  as 
described  above.  The  address  of  the  first  character  in  the  string  is  pushed  on  the  stack.  Returning  strings 
from  an  external  interfaced  subprogram  to  Ada  requires  special  handling  because  the  descriptors  for  string 
types  may  differ  between  Ada  and  the  called  subprogram  written  in  other  languagea 

Array  element  allocation,  layout,  and  alignment  are  described  in  Section  F  1 2  of  this  appendix.  Array 
types  cannot  be  returned  as  function  results  from  external  interfaced  subprograma 


F  14.1.4  Record  Types 

Records  {LRM  3.7)  are  always  passed  by  reference  in  the  HP  implementation  of  Ada,  pushing  the  32 -bit 
address  of  the  first  component  of  the  record  on  the  stack. 

Unlike  arrays,  however,  the  individual  components  of  a  record  may  have  been  reordered  internally  by  the 
Ada  compiler.  This  means  that  the  implementation  of  record  components  can  be  in  an  order  different 
from  the  declarative  order.  Ada  semantics  do  not  require  a  specific  ordering  of  record  components. 

You  can  control  the  layout  of  individual  record  components  by  using  record  representation  clauses. 
However,  in  the  absence  of  a  complete  record  specification,  the  exact  internal  structure  of  a  record  in 
memory  caxmot  be  known  directly  at  the  time  of  coding  (see  Section  F  1 2X  The  attribute  '  POS  can  be 
used  to  locate  the  offset  of  a  record  component  with  respect  to  the  starting  address  of  the  record.  By 
passing  such  a  record  component  offset  to  a  called  subprogram  (in  addition  to  passing  the  record),  Ada 
record  components  may  be  directly  accessed  by  an  interfaced  subprogram.  Offsets  are  relative  to  the 
starting  address  of  the  record.  The  starting  address  of  the  record  is  derived  from  the  following; 

•  the  record  passed  u  a  parameter  (records  are  always  passed  by  reference). 

•  the  attribute  'ADDRESS  of  the  record  passed  as  a  parameter. 

•  an  accea  to  the  record  passed  u  a  parameter. 

Direct  assignment  to  a  discriminant  of  a  record  is  not  allowed  in  Ada  [LRM,  Section  3.7.1).  A 
discriminant  cannot  passed  as  an  actual  parameter  of  mode  OUT  or  IN  OUT.  This  restriction  applies 
equally  to  HP  Ada  subprograms  and  to  external  interfaced  subprograms  written  in  other  languages.  If  an 
interfaced  program  is  given  access  to  the  whole  record  (rather  than  individual  components),  that  code 
should  not  change  the  discriminant  value.  Record  element  allocation,  layout,  and  alignment  are  described 
in  Section  F  1 2. 

In  HP  Ada,  records  are  packed  and  variant  record  parts  are  overlaid;  the  size  of  the  record  is  the  longest 
variant  part.  If  a  record  contains  discriminanu  or  composite  components  having  a  dynamic  size,  the 
compiler  may  add  implicit  components  to  the  record.  These  components  can  include  a  variant  index, 
record  or  component  size,  and  portions  of  array  descriptors. 

Dynamic  components  and  components  whose  size  depends  upon  record  discriminant  values  are 
implemented  indirectly  within  the  record  by  using  descriptors. 
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Record  types  cannot  be  returned  as  function  results  from  external  interfaced  subprograms. 


F  14.1.5  Task  Types 

Task  types  cannot  be  passed  to  an  external  procedure  or  function  as  parameters  in  HP  Ada.  Task  types 
cannot  returned  as  function  results  from  external  interfaced  subprograms. 

The  HP  implementation  of  tasking  in  Ada  uses  asynchronous  HP-UX  signals.  The  asynchronous  signals 
SICALRM  and  SICVTALRM  are  used  by  the  Ada  run  time  in  the  HP  9000  Series  300  implementation.  If  an 
external  subprogram  called  within  a  tasking  Ada  main  subprogram  is  interrupted  either  by  SICALRM  or 
SICVTALRM  while  executing  an  HP-UX  primitive,  problems  may  arise.  (See  Section  9,  The  HP  Ada 
Compilation  System  and  HP-UX  SignaliT,  for  more  information.)  You  must  therefore  disable  SICALRM 
and  SICVTALRM  before  any  HP-UX  primitive  is  called  from  within  the  external  interfaced  subprogram 
written  in  a  language  different  from  Ada.  SICALRM  and  SICVTALRM  must  be  re-enabled  after 
completion  of  the  execution  of  the  primitive,  and  the  SICALRM  and  SICVTALRM  interrupt  cycle  should 
then  be  restarted  using  the  HP-UX  routine  alarm. 

An  alternative  method  of  protecting  interfaced  code  from  signals  is  described  in  the  Ada  User's  Guide 
section  on  execution -time  topics.  Two  procedures,  SUSPEND_ADA_TASKINC  and  RESUME_ADA_TASKINC, 
from  the  HP  supplied  package  UNIX^^ENV  can  be  used  to  access  signal  protection  primitives  inside  Ada 
programs.  Calls  to  these  routines  could  be  used  within  an  Ada  program  to  surround  a  critical  section  of 
Ada  code  or  a  call  to  external  interfaced  subprogram  code  that  contains  a  critical  section. 

See  Sections  F  9  and  F  1 4. 7  for  more  detail  on  the  suggested  handling  of  these  signals. 


F  14.1.6  Private  Types 

e 

Private  types  cannot  be  returned  as  function  results  from  external  interfaced  subprograms. 
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F  14.2  Calling  Assembly  Language  Subprograms 


When  calling  interfaced  assembly  language  subprograms,  specify  the  named  external  subprogram  in  a 
compiler  directive: 

pragma  INTERFACE  (ASSEMBLER,  Adajsubprogrwtijtoumy, 

Note  that  the  language _ type  specification  is  ASSEMBLER  and  not  ASSEMBLY.  This  description  refers  to 

the  HP  assembly  language  for  the  MC680x0  microprocessor  family  (68K  assembly  language)  upon  which 
the  Series  300  family  is  based. 

When  calling  interfaced  68fC  assembly  language  subprograms,  scalar  and  access  parameters  of  mode  IN  are 
passed  by  value;  the  value  of  the  parameter  object  is  copied  and  pushed  on  the  stack.  All  other  types  of 
IN  parameters  (array,  records)  and  parameters  of  mode  OUT  and  IN  OUT  are  passed  by  reference;  the 
address  of  the  parameter  object  is  pushed  on  the  stack. 

When  calling  68K  assembly  language  subprograms,  the  processor  scratch  registers  are  considered  to  be  AO, 
Al,  DO,  or  Dl.  In  external  interfaced  68K  assembly  subprograms,  processor  registers  D2  through  D7,  and 
A  2  through  A  7  must  be  saved  on  entry  and  restored  before  returning  to  the  Ada  caller.  The  Ada 
compiler  expects  those  registers  to  be  unchanged  across  a  call  to  an  external  interfaced  subprogram.  Only 
registers  used  in  the  called  68K  assembly  language  subprogram  must  be  saved  and  restored,  but  you  are 
responsible  for  ensuring  that  all  register  contents  (except  for  designated  scratch  registers)  are  unchanged. 

The  results  returned  by  external  function  subprograms  are  expected  to  be  in  the  register  DO  if  the  result  is 
scalar,  or  in  register  AO  if  the  result  it  an  access  value.  LONC^^FLOAT  values  that  are  represented  as 
64-bits  are  returned  in  two  registers:  DO  holds  the  low-level  woriTand  DI  holds  the  high  level  word. 

Only  scalar  types  (integer,  floating  point,  character,  boolean,  and  enumeration  types)  and  access  types  are 
allowed  for  the  result  returned  by  an  external  interfaced  subprogram  written  in  68K  assembly  language. 

For  more  information  on  68K  assembly  language  interfacing,  see  the  HP-UX  Assembler  Reference 
Manual  and  ADA  Tutorial,  the  MC68020  32-Bit  Microprocessor  User's  Manual,  and  the  MC68881 
Floating-Point  Coprocessor  User's  Manual 


F  14.2.1  Scalar  Types  and  Assembly  Language  Subprograms 

Scalar  types  include  integer,  real,  and  enumeration  typea  The  predefined  enumeration  types  CHARACTER 
and  BOOLEAN  are  also  scalar  typea  This  section  discusses  things  you  should  consider  when  passing  scalar 
types  to  and  from  interfaced  68K  assembly  language  subprograma 


F  14.2.1.1  Integer  Types  and  Assembly  Language  Subprograms 

>A'hen  passed  by  value  to  an  assembler  subprogram,  values  of  type  INTEGER  and  SHORT_INTECER  are 
copied  and  pushed  on  the  stack  without  alteration.  An  Ada  INTEGER  is  stacked  in  a  32-bit  container  (a 
Long  Word  in  68K  assembly  language)  and  an  Ada  SHORT_INTECER  is  stacked  in  a  16-bit  container  (a 
Word  in  68K  68K  assembly  language).  Values  of  type  SHORT__SHORT_INTECER  are  copied  and  pushed  on 
the  stack  as  the  most  significant  (leftmost)  8  bits  of  a  16-bit  word;  the  low  order  8  bits  are  meaningless 
and  should  net  be  accessed. 
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When  passed  by  reference,  the  value  is  not  altered  and  a  32-bit  address  pointer  to  the  integer  object  is 
pushed  on  the  stack. 

Table  F- 1 4  summariies  the  integer  correspondence  between  Ada  and  HP  assembly  language. 


Table  F-14.  HP  Ada/68K  Assembly  Language  Integer  Correspondence 


Ada 

68K  Assembly  Language 

Bit  Length 

SHORT_SHORT_I NTECER 

Byu 

8 

SHORTJNTECER 

Word 

16 

INTEGER 

Long  Word 

32 

All  integer  types  are  allowed  for  the  result  returned  by  an  external  interfaced  subprogram  written  in  68K 
assembly  language.  The  results  returned  by  external  function  subprograms  are  expected  to  be  in  the 
register  DO  if  the  result  is  an  integer  type,  or  in  register  AO  if  the  result  is  an  access  to  an  integer  value. 


F  14.2.1.2  Enumeration  Types  and  Assembly  Language  Subprograms 

When  passed  by  value  to  an  assembler  subprogram,  values  of  enumeration  types  represented  by  1 6  bits  are 
copied  and  pushed  on  the  stack  without  alteration.  Values  of  enumeration  types  represented  by  8  bits  are 
copied  and  pushed  on  the  stack  u  the  roost  significant  Oeftmost)  8  bits  of  a  16-bit  word;  the  low  order  8 
bits  are  meaningless  and  should  not  be  accessed. 

When  passed  by  reference,  the  value  is  not  altered  and  a  32-bit  address  pointer  to  the  enumeration  object 
is  pushed  on  the  stacL 

Enumeration  types  are  allowed  for  the  result  returned  by  an  external  interfaced  subprogram  written  in 
68K  assembly  language.  The  results  returned  by  external  function  subprograms  are  expected  to  be  in  the 
register  DO  if  the  result  is  an  enumeration  type,  or  in  register  AO  if  the  result  it  an  access  to  an 
enumeration  value. 


F  14.2.1.3  Boolean  Types  and  Assembly  Language  Subprograms 

Although  a  predefined  enumeration  type,  Ada  boolean  values  are  represented  in  8  bits  in  a  manner 
different  from  other  enumeration  types  in  the  HP  implementation  of  Ada  .  The  internal  representation 

of  FALSE  corresponds  to  2#0000 _ 00004^  and  TRUE  corresponds  to  2#1 1 1 1__1 1 1 14^  (that  is,  all  zeros  or 

all  ones  in  8  bits).  Note  that  the  value  of  BOOLEAN 'POS (TRUE)  is  1  and  the  value  of 
BOOLEAN 'POS( FALSE)  is  a 

When  passed  by  value  to  an  interfaced  68K  assembly  language  subprogram,  values  of  type  BOOLEAN  are 
copied,  and  pushed  on  the  stack  as  the  most  significant  (leftmost)  8  bits  of  a  16-bit  word;  the  low  order  8 
bits  are  meaningless  and  should  not  be  accessed 

When  passed  by  reference  to  an  interfaced  68K  assembly  language  subprogram,  the  boolean  value  is  not 
altered  and  a  3  2 -bit  address  pointer  to  the  object  is  pushed  on  the  stack. 
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Boolean  types  are  allowed  for  the  result  returned  by  an  external  interfaced  subprogram  written  in  68K 
assembly  language,  when  care  is  taken  to  observe  the  internal  representation.  The  results  returned  by 
external  function  subprograms  are  expected  to  be  in  the  register  DO  if  the  result  is  a  boolean  type,  or  in 
register  AO  if  the  result  is  an  access  to  a  boolean  value. 


F  14.2.1.4  Character  Types  and  Assembly  Language  Subprograms 

Character  types,  which  are  predefined  enumeration  types,  are  represented  as  8  bits  in  the  HP 
implementation  of  Ada.  When  passed  by  value  to  an  interfaced  subprogram  written  in  68K  assembly 
language,  values  of  type  CHARACTER  are  pushed  on  the  stack  as  the  most  significant  (leftmost)  8  bits  of  a 
1 6-bit  word;  the  low  order  8  bits  are  meaningless  and  should  not  be  accessed. 

Wlien  passed  by  reference  to  an  interfaced  subprogram  written  in  68K  assembly  language,  the  character 
values  are  not  altered  and  a  32-bit  pointer  to  the  address  of  the  character  object  is  pushed  on  the  stack. 

Character  types  are  allowed  for  the  result  returned  by  an  external  interfaced  subprogram  written  in  68K 
assembly  language.  The  results  returned  by  external  function  subprograms  are  expected  to  be  in  the 
register  DO  if  the  result  is  a  character  type,  or  in  register  AO  if  the  result  is  an  access  to  a  character  value. 


F  14.2.1.5  Real  Types  and  Assembly  Language  Subprograms 

When  passed  by  value  to  interfaced  subprograms  written  in  68K  assembly  language,  values  of  type  FLOAT 
and  LONC^FLOAT  are  copied  and  pushed  on  the  stack  without  alteration.  Specifically,  Ada  objects  of  type 
FLOAT ar^copied  as  a  68K  assembler  Long  Word  (32  bits)  and  Ada  LONC^^FLOAT  objects  are  copied  as  two 
68K  assembler  Long  Words  (64  bits). 

When  passed  by  reference  to  an  interfaced  subprogram  written  iir  68K  assembly  language,  the  values  are 
not  altered  and  a  32-bit  address  of  the  object  is  pushed  on  the  stack. 

Floating  point  types  are  allowed  for  the  result  returned  by  an  external  interfaced  subprogram  written  in 
68K  asembly  language.  The  results  returned  by  external  function  subprograms  are  expected  to  be  in  the 
register  DO  if  the  result  it  a  FLOAT  type.  If  the  results  returned  by  external  function  subprograms  are 
LONC^FLOAT  type,  the  results  are  expected  to  be  contained  in  the  register  DO  and  Dl.  The  low-level 
word  Is  in  DO  and  the  high-level  word  it  in  Dl.  The  result  will  be  returned  in  register  AO  if  the  result  is 
an  access  to  a  FLOAT  or  LONG  FLOAT  value. 


F  14.2.2  Access  Types  and  Assembly  Language  Subprograms 

See  general  comments  on  parameter  passing  in  Section  F  1 4. 1. 2. 

Access  types  are  allowed  for  the  result  returned  by  an  external  interfaced  subprogram  written  in  68K 
assembly  language.  Th  :  results  returned  by  external  function  subprograms  are  expected  to  be  in  the 
register  AO  if  the  result  is  an  access  value. 


F  14.2.3  Array  Types  rnd  Assembly  Language  Subprograms 

See  general  comments  on  parameter  passing  in  Section  F  1 4. 1. 3. 

Array  types  cannot  be  returned  as  function  results  from  external  interfaced  subprograms. 
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F  14.2.4  Record  Types  and  Assembly  Language  Subprograms 

See  general  comments  on  parameter  passing  in  Section  F  1 4. 1. 4. 

Record  types  cannot  be  returned  as  function  results  from  external  interfaced  subprograms. 

F  14.2.5  Task  Types  and  Assembly  Language  Subprograms 

Task  types  cannot  be  passed  as  parameters  in  HP  Ada.  Task  types  cannot  be  returned  as  function  results 
from  external  subprograms. 

F  14.2.6  Private  Types  and  Assembly  Language  Subprograms 

Private  types  cannot  be  passed  as  parameters  in  HP  Ada.  Private  types  cannot  be  returned  as  function 
results  from  external  interfaced  subprograms. 
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F  14.3  Calling  HP  C  Subprograms 

-  'When  callins  interfaced  HP  C  subprograms,  the  form 

pragma  INTERFACE  (C,  Adajsubprogramjteum) 

is  used  to  identify  the  need  for  HP  C  parameter  passing  conventions. 

To  call  the  following  HP  C  subroutine  (assuming  call  by  value  parameter  passing): 

void  c_aub  (para) 
int  parm; 

{ 

•  a  a 

> 

Ada  requires  an  interfaced  subprogram  declaration: 

procadura  C  SUB  (PARM1  :  in  INTEGER); 
pragma  INTERFACE  (C.  C_SUB)t 

The  external  name  specified  in  the  Ada  interface  declaration  can  be  any  Ada  identifier.  No  specul 
handling  of  leading  underscores  is  required  as  this  is  handled  by  the  compiler  to  conform  to  standard 
calling  conventions.  Pragma  INTERFACE  ensures  that  the  underscore  required  in  front  of  the  HP  C 
subroutine  name  is  correctly  prepended  by  the  compiler.  Pragma  INTERFACE^NAME  is  required  if  the 
Ada  identifier  differs  from  the  HP  C  subprogram  name. 

Note  that  the  parameter  in  the  preceding  example  may  be  of  mode  IN  or  mode  IN  OUT.  In  HP  C,  user 
parameten  may  be  pasted  by  value  or  by  reference. 

When  calling  interfaced  HP  C  subprograms,  scalar  and  access  parameters  of  mode  IN  are  passed  by  value; 
the  value  of  the  parameter  object  is  copied  and  pushed  on  the  stack.  All  other  types  of  IN  parameten 
(array,  records)  and  parameten  of  mode  OUT  and  IN  OUT  are  passed  by  reference;  the  address  of  the 
parameter  object  is  pushed  on  the  stack. 

In  general,  parameten  passed  to  HP  C  subprograms  from  HP  Ada  programs  are  passed  in  32>bit 
containers,  except  for  64-bit  real  quantitiea  Real  values  stored  in  32  bits  and  real  values  stored  in  64 
bits  are  passed  intact  as  parameten  between  external  interfaced  subprograms  written  in  HP  C  and  your 
Ada  program.  The  capability  to  automatically  extend  32-bit  real  types  (Ada  FLOAT)  to  64-bit  v^ues 
when  passed  as  parameten  is  not  supponed  by  the  HP  Ada  compiler. 

Only  scalar  types  (integer,  floating  point,  character,  boolean,  and  enumeration  types)  and  access  types  are 
allowed  for  the  result  returned  by  an  external  interfaced  function  subprogram  written  in  HP  C 

When  binding  and  linking  Ada  programs  with  interfaced  subprograms  written  in  HP  C,  the  libraries 
libe.a  and  libtn.a  are  usually  required.  The  mother  program  ada(1)  will  automatically  provide  the 
-Ic  -Im  directives  to  the  linkep.  You  are  not  required  to  specify  "-Ic  -Im"  when  binding  the  Ada 
program  on  the  ada  command  line. 

For  more  information  about  C  Language  interfacing,  see  the  following  manuals:  HP-UX  Concepts  and 
Tutorials:  Programming  Environment,  the  HP-UX  Concepts  and  Tutorials:  Device  I/O  and  User 
Interfacing,  and  the  HP-UX  Portability  Guide.  For  more  general  information  about  passing  Ada  types,  see 
Section  14. 1. 
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F  14.3.1  Scalar  Types  and  HP  C  Subprograms 

Scalar  types  are  a  class  of  Ada  types  that  includes  integer,  real,  and  enumeration  types.  Character  and 
boolean  types  are  also  scalar  types  because  they  are  predefined  enumeration  types.  This  section  discusses 
passing  scalar  types  between  Ada  programs  and  subprograms  written  in  HP  C 

Scalar  type  parameters  of  mode  IN  are  passed  by  value.  Scalar  type  parameters  of  mode  OUT  or  IN  OUT 
are  passed  by  reference. 


F  14.3.1.1  Integer  Types  and  HP  C  Subprograms 

When  passed  by  value  to  an  HP  C  subprogram,  all  integer  values  are  extended  to  32  bits  to  conform  to  the 
HP  C  parameter  passing  conventions.  HP  Ada  INTEGER  (32  bits)  types  passed  by  value  are  pushed  onto 
the  stack  without  alteration.  Values  of  type  SH0RT_SH0RT_1NTECER  (8  bits)  and  type  SHORT_INT£GER 
(16  bits)  are  sign  extended  (on  the  left)  to  32  bits  and  pushed  on  the  stack. 

When  passed  by  reference,  the  integer  values  are  not  changed;  the  original  values  are  not  sign  extended  to 
32  bits.  The  32-bit  address  pointer  to  the  integer  object  is  pushed  on  the  suck. 

When  passing  integers  by  reference,  note  that  an  Ada  SHORTjSHORT_INTEGER  (8  bits)  has  no  equivalent 
integer  representation  in  HP  C  ” 

Table  F- 1  i  summarizes  the  integer  correspondence  between  Ada  and  C 


Table  F-15.  HP  Ada/HP  C  Integer  Correspondence 


Ada 

HPC 

Bit  Length 

SHORT_SHORT_I NTECER 

no  equivalent  represenUtion 

8 

short  and  short  Int 

16 

INTEGER 

.32 

If  a  SHORT_SHORT_INTEGER  is  passed  by  reference  from  HP  Ada  to  HP  C,  the  external  subprogram  must 
treat  the  referencT  as  being  a  pointer  to  char,  and  not  as  a  pointer  to  short.  Otherwise  an  Ada 
SHORT_SHORT__INTEGER  cannot  be  meaningfully  accessed  by  HP  C  subprograms  as  any  type  of  integer. 
Because  HP  C  permits  integer  operations  on  objecu  of  type  char,  an  Ada  SHORT__SHORT_INTEGER  can  be 
used  and  modified  (at  an  object  of  type  char)  in  an  interfaced  subprogram.  ~  ~ 

All  Ada  integer  types  are  allowed  for  the  result  returned  by  an  external  interfaced  subprogram  written  in 
HP  C  if  are  is  taken  with  respect  to  differences  in  the  interpretation  of  8-bit  quantities. 
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F  14.3.1.2  Enumeration  Types  and  HP  C  Subprograms 

'When  HP  Ada  passes  Ada  enumeration  types  by  value  to  an  HP  C  subprogram,  the  enumeration  types  are 
treated  as  the  underlying  integer  value.  That  value  is  either  an  8-bit  quantity  or  a  16-bit  quantity  (see 
Section  F  12)  and  is  passed  according  to  the  convention  given  previously  for  integer  values.  When  passed 
by  value,  the  integer  is  copied  to  the  stack  and  is  automatically  extended  to  32  bits. 

When  passed  by  reference,  the  value  is  not  altered  by  sign  extension  and  a  32-bit  address  pointer  to  the 
enumeration  object  is  pushed  on  the  stack. 

Enumeration  types  in  HP  C  are  represented  in  the  same  way  as  in  Ada,  except  that  the  values  are  always 
expressed  as  16-bit  integers  (no  matter  how  many  elements  there  are).  When  HP  C  passes  enumeration 
types  as  value  parameters,  the  values  are  extended  to  32  bits,  with  the  high  order  16  bits  disregarded. 
A^’s  automatic  extension  to  32  bits  meant  that  Ada  enumeration  type  values  are  in  the  correct  form  for 
HP  C  subprograms  whether  stored  in  8  or  1 6  bits. 

When  passed  by  reference,  the  original  values  are  not  extended.  Therefore  Ada’s  8 -bit  enumeration 
objects  have  no  representation  in  HP  C  and  cannot  be  used  directly  by  an  HP  C  subprogram.  However,  an 
Ada  8-bit  enumeration  value  passed  by  reference  to  HP  C  can  be  accessed  as  a  character  in  C  (using 
point«r-lo-char).  Because  HP  C  permits  integer  operations  on  objects  of  type  char,  an  Ada  8-bit 
enumeration  value  passed  by  reference  to  HP  C  csin  successfully  used  and  modified  by  HP  C  (as  an 
object  of  type  char).  Enumeration  types  are  allowed  for  the  result  returned  by  an  external  interfaced 
subprogram  written  in  HP  C 


F  14.3.1.3  Boolean  Types  and  HP  C  Subprograms 

The  type  boolean  is  not  defined  in  HP  C,  and  the  HP  Ada  representation  of  booleans  does  not  correspond 
to  any  type  in  HP  C  Ada  booleans  can  be  converted  to  integerrand  then  passed  to  external  interfaced 
subprograms  written  in  HP  C 

In  Ada,  BOOLEAN 'POS (TRUE)  has  a  result  of  type  UNIVERSAL__^INtE(;ER  with  a  value  of  one  and 
BOOLEAN 'POS(FALSE)  has  a  result  of  type  UNIVERSAL^INTECER  with  a  value  of  tero.  Thus  the  Ada 
attribute  '  POS  can  be  used  to  convert  an  Ada  boolean  type  to  an  integer  type.  The  integer  type  can  then 
be  passed  to  an  HP  C  external  subprogram. 

Boolean  types  are  represented  internally  as  an  8 -bit  enumeration  type  of  the  predefined  type  (FALSE, 
TRUE).  Although  a  predefined  enumeration  type,  Ada  boolean  values  are  represented  in  8  bits  in  a 
manner  different  from  other  enumeration  types  in  the  HP  implementation  of  Ada  .  The  internal 

representation  of  FALSE  corresponds  to  2#0000 _ 0000#  and  TRUE  corresponds  to  2#1 1 1 1 _ 1 1 1 1#  (that 

is,  all  zeros  or  all  ones  in  8  bits).  Note  that  the  value  of  BOOLEAN 'POS  (TRUE)  is  1  and  the  value  of 
BOOLEAN 'PCS (FALSE)  is  0.  Thus  Ada  booleans  could  also  be  passed  as  enumeration  types  in  the  same 
way  as  they  are  passed  as  integer  types.  To  ensure  portability,  however,  passing  the  'POS  of  a  boolean 
type  as  an  integer  is  recommended. 

Boolean  types  are  allowed  for  the  result  returned  by  an  external  interfaced  subprogram  written  in  HP  C, 
when  care  is  taken  to  observe  the  internal  representation. 
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F  14.3.1.4  Character  Types  and  HP  C  Subprograms 

Ada  character  types  (including  the  predefined  type  CHARACTER)  correspond  exactly  with  the  type  char  in 
HP  C  Both  the  Ada  and  HP  C  types  have  the  same  internal  representation  and  size. 

Character  types  are  represented  as  8  bits  in  the  HP  implementation  of  Ada.  When  passed  by  value  to  an 
interfaced  subprogram  written  in  HP  C,  values  of  type  character  are  zero  extended  on  the  left  to  32  bits 
and  pushed  on  the  suck;  the  actual  value  is  the  low-order  (rightmost)  8  bits. 

When  passed  by  reference,  the  character  values  are  not  altered  and  a  32-bit  address  of  the  character 
object  is  pushed  on  the  suck. 

Character  values,  whether  passed  by  value  or  reference  to  HP  C,  can  be  used  directly  by  the  interfaced 
subprogram  as  values  of  type  char  (using  point«r-to-char  when  passed  by  reference). 

Character  types  are  allowed  for  the  result  returned  by  an  external  interfaced  subprogram  written  in 
HPC 


F  14.3.1.5  Real  Types  and  HP  C  Subprograms 

This  section  discusses  passing  fixed  point  types  and  floating  point  types  to  HP  C 

Fixed  Point  Reai  Types 

Ada  fixed  point  types  are  not  supported  as  parameters  or  as  results  of  external  subprograms.  Ada  fixed 
point  t)'pes  cannot  be  returned  as  function  results  from  interfaced  subprograms  written  in  HP  C  For 
information  on  the  Ada  type  STRING,  see  Section  F  14. 3. 3  because  Ada  strings  are  a  special  case  of  arrays 
of  characters.  * 

Floating  Point  Real  Types 

Both  Ada  and  HPC  use  the  IEEE  (draft  10.0,  P754)  floating  point  conventions  for  both  32-bit  and 
64-bit  floating  point  real  numbers.  The  HP  C  type  float  and  the  Ada  type  FLOAT  are  implemented  oi 
32  bits  and  have  both  the  represenution  and  length  of  the  IEEE  standard  32-bit  real.  The  HP  C  type 
double  and  the  Ada  type  LONG_FLOAT  are  implemented  on  64  bits.  Both  have  the  represenution  and 
length  of  the  IEEE  sundard  64-bit  real 

HP  C  parameter  passing  conventions  require  that  all  32-bit  (that  is,  C  type  float)  values  be  extended  to 
64  bits  (C  type  double)  when  they  are  passed  as  parameters  or  returned  u  results.  The  HP  Ada  compiler 
supports  this  convention  for  Ada  type  LONC_FLOAT,  but  docs  not  follow  the  convention  for  Ada  type 
FLOAT.  Thus  an  Ada  FLOAT  value  may  not  be  passed  by  value  directly  to  HP  C,  nor  returned  from  HP  C 
An  Ada  FLOAT  value  may  be  passed  by  reference  to  HP  C,  because  C  does  not  expect  such  parameters  to 
be  extended.  A  beneficial  conmquence  of  this  restriction  on  32-bit  floating  point  values  is  that  the 
3  2 -bit  HP  C  math  library  is  callable  from  within  Ada  programs. 

When  passed  by  value  to  interfaced  subprograms  written  in  HP  C,  values  of  type  FLOAT  and  LONC_FLOAT 
are  copied,  and  pushed  on  the  stack.  Float  values  stored  in  32  bits  are  pushed  on  the  stack  as  32-bit 
quantities  (without  automatic  extension  to  64  bits)  and  values  stored  in  64  bits  are  pushed  on  the  stack  as 
6  4 -bit  quantities. 

When  passed  by  reference  to  an  interfaced  subprogram  written  in  HP  C,  the  original  values  are  not  altered 
and  a  32-bit  address  of  the  object  is  pushed  on  the  stack. 
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The  64-bit  floating  point  type  LONG_rLOAT  can  be  returned  as  a  result  from  an  external  interfaced 
function  subprogram  written  in  HP  C 

The  32-bit  floating  point  type  FLOAT  cannot  be  directly  returned  as  a  result  from  an  external  interfaced 
function  subprogram  written  in  HP  C.  It  is  possible  to  pass  Ada  FLOAT  values  to  HP  C  by  value  and  to 
return  Ada  FLOAT  values  from  HP  C  indirectly  if  the  C  routine  uses  a  union  containing  a  float  field 
and  a  long  int  field. 

A  sample  HP  C  function  to  illustrate  this  follows.  This  example  computes  the  square  of  an  Ada  FLOAT 
value.  The  parameter  in  the  C  function  is  declared  to  be  a  union  type  that  matches  the  size  of  the  Ada 
FLOAT  being  passed  (32  bits).  The  function  uses  the  float  field  (f)  of  the  union  to  access  the  Ada 
floating  value.  The  function  stores  the  result  in  a  union  of  the  same  type.  It  returns  the  long  int 
field  (i)  of  the  union  that  overlays  (occupies  the  same  storage  as)  the  float  field  .  The  long  int  field 
is  returned  in  a  manner  in  which  Ada  expects  a  FLOAT  function  result  (occupying  32  bits)  to  be  returned. 
Note  that  neither  the  float  field  of  the  union  nor  the  entire  union  should  be  returned.  (The  former 
would  be  returned  incorrectly  as  a  double  and  the  latter  as  an  HP  C  structured  type  that  would  be 
inconsistent  with  the  expected  Ada  FLOAT  result) 

The  following  example  indirectly  returns  a  float  result  to  Ada. 

typadaf  union  {  float  f;  long  int  1}  ada_float; 

int  aquarait  (pam)  ada  float  pam; 

{ 

ada^float  result; 

result. f  »  parm.f  •  parm.f; 

return  result.!;  ' 

> 


A  sample  Ada  procedure  to  call  this  HP  C  function  is  the  following: 

--example  to  workaround  restriction  on  Ada  FLOAT  result 

with  TEXT_IO; 

procedure  SOUARE^Pl  la 

pi  !  cons  '  nt  FLOAT  :«3. 1415926; 

pi2  :  FLOAi ; 

package  FLOATER  is  new  TEXT_IO.FLOAT_IO(FLOAT) ; 

function  SQUARE  (  f  ;  FLOAT)  return  FLOAT; 

pragma  INTERFACE  (C,  SQUARE); 

pragma  INTERFACE_NAME  (SQUARE,  "aquareit") ; 

begin  —  SQUARE  PI 
pi2  :«  SQUARE  (pi); 

TEXT  10. PUT  ("PI  squared  «  "); 

FLOATER. PUT  (pi2); 

TEXT  10. NEW  LINE; 
end  SQUARE  PI;~ 


B-70 


Implennentation-Dependent  Characteristics 


F  14.3.2  Access  Types  and  HP  C  Subprograms 

Ada  access  types  are  pointers  to  Ada  objects.  Ada  access  types  to  simple  objects  (scalar  type  or  other  access 
type  objects)  are  actually  pointers  to  the  designated  object.  Ada  access  type  values  pointing  to  composite 
types  (record  or  array  types)  are  pointers  to  Ada  descriptors  for  that  object  rather  than  pointers  to  the 
actual  object. 


NOTE 


You  are  cautioned  that  the  descriptors  used  by  HP  Ada  are  not  identical  to 
descriptors  used  by  HP  C  An  Ada  access  type  value  that  points  to  a 
composite  type  has  no  meaning  when  passed  as  a  parameter  to  a  subprogram 
written  in  HP  C 


Ada  access  types  of  mode  IN  are  passed  by  value.  When  an  access  type  is  passed  by  value,  a  copy  of  the 
32-bit  object  address  is  pushed  on  th:  nack.  If  the  type  is  passed  by  reference,  however,  a  32-bit  address 
pointer  to  the  object  address  location  is  pushed  on  the  stack.  This  is  effectively  a  double  indirect  address 
to  the  underlying  object  (See  Figure  F-1  in  Section  14. 1.2). 

Ada  access  types  may  be  returned  as  function  results  from  external  interfaced  subprograms  written  in 
HPC 

An  object  designated  by  an  Ada  access  type  can  be  passed  to  an  HP  C  external  subprogram  subject  to  rules 
applicable  to  the  type  of  the  underlying  object 


F  14.3.3  Array  Types  and  HP  C  Subprograms  ' 

For  more  information,  see  the  comments  on  general  parameter  passing  in  Section  F  14.1.3.  Note  that 
Ada  arrays  with  SHORT_SHORT^INTEGER  and  8-bit  enumeration  type  components  do  not  correspond 
directly  to  any  HPC  array  type.  Such  arrays  can  be  accessed  in  C  u  an  array  of  type  char.  The 
subprogram  must  access  and  modify  such  elements  in  a  manner  appropriate  to  the  actual  Ada  type;  note 
that  an  Ada  8 -bit  enumeration  type  has  a  limited  range  (0  through  128).  Arrays  are  not  supported  as 
function  results  from  external  interfaced  HP  C  function  subprograms. 

HP  Ada  strings  are  one  special  case  of  arrays  that  do  not  end  with  an  ASCII  null  character  (\000),  as 
required  of  strings  in  HP  C  You  must  append  a  null  character  to  the  end  of  an  Ada  string,  if  that  string 
is  to  be  sent  to  an  external  interfaced  HP  C  subprogram.  The  excess  null  terminator  character  may  need 
to  be  removed  from  strings  passed  from  HP  C  to  Ada.  Caution  is  required  regarding  the  assignment  of 
unconstrained  strings  into  array  objects  in  Ada.  In  particular,  there  is  a  restriction  that  an  interfaced 
external  subprogram  cannot  directly  return  an  unconstrained  array  (such  as  a  string). 

The  examples  on  the  next  two  pages  illustrate  the  handling  of  strings  in  C  and  in  Ada.  In  the  first 
example,  an  Ada  string  is  passed  to  C  Note  the  need  to  explicitly  attach  a  null  character  so  that  the  C 
routine  can  locate  the  end  of  the  string. 
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The  HP  C  routine: 

--passing  an  Ada  string  to  a  C  routine 
void  raad_ada__str  (var_str) 
char  *var  str; 

< 

printf  (“C:  Received  value  was  :  %a  \n'\  var  str); 


The  Ada  routine: 

Procedure  send_ada_str  it 

—  Declare  an  interfaced  procedure  that  sends  an 
—  Ada-String  to  a  C-subprograa 
procedure  READ  ADA  STR  (  VAR  STR  :  STRING); 
pragma  INTERFACE  (C,  READ__AOA_STR ) ; 

begin  —  send__ada_str 

--  Test  the  passing  of  an  Ada  string  to  a  C  routine 
READ_ADA_STR  {  "Ada  test  string  sent  to  C  **  It  ASCII. NUL); 

end  send  ada  str  ; 


In  the  second  example,  a  C  string  is  passed  to  Ada.  Note  the  need  for  Ada  to  determine  the  length  of  the 
string  parameter  explicitly  by  using  a  brute  force  loop  that  reads,  counts,  and  compares  each  character 
while  looking  for  the  end  of  the  C  string.  The  length  is  required  because  Ada  needs  a  string  of  the  correct 
length  into  which  it  can  assign  the  characters.  Fortunately,  Ada  supports  the  allocation  of  such  a  string 
(of  arbitrary  but  fixed  length)  at  run  time. 

The  HP  C  routine: 

—  Reading  a  variable  length  string  from  a  C  function 
char  *read  c  str() 

{ 

char  •local_string; 

local_string  •  "a  C  string  for  Ada.*'; 
return  local  string; 

} 
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Thtt  Ada  routina: 

with  taxt^io; 

Procedura  raad_cstring  it 

—  Maximum  siza  string  axpactad  from  C  func. 

MAX_STR_SI2E  :  constant  :■  255  ; 

subtypa  MAX  STR  is  STRING  (  t  ..  MAX  STR  SIZE  ); 
typa  ACC  STR  is  accass  MAX  STR; 

READ_STR~:  ACC_^STR; 

—  Daelara  an  intarfacad  procadura  that  raturns  a  pointar 
to  a  C  string  (actually  a  pointar  to  a  eharactar) 
function  READ  C  STR  ratum  ACC  STR; 
pragma  INTERFACE  (C,  READ^C^STR); 

C_STRINC_LENGTH  :  NATURAL  :•  0  ;  —sat  langth 

--initially  to  zaro 

bagin  --  raad_^cttring 

—  Read  an  unconstrainad  string  from  a  C  function  that  ratuma 
--  a  variabla  langth,  null  tarminatad  string  of  charactara. 

—  assign  tha  pointar  to  tha  C  string  to  a  statically  sizad 
--  Ada  string  accass,  so  both  point  to  sama  storaga. 

READ_STR  :■  READ__C_STR  ; 

—  caleulata  tha  langth  of  tha  C  string  axcluding  null  tarminator 
whila  (READ  STR. all  (  C  STRING  LENGTH  ♦  1)  /■  ASCII. NUL)  loop 
C^STRING^^LENCTH  :•  C_STRINC_LENCTH  ♦I; 

and  loopT  ”  ” 

daelara  —  block 

—  allocata  an  Ada  string  of  axactly  tha  right  langth 

—  to  hold  tha  C  string  (axcluding  tha  null  tarminator) 

ADA^STRINC  ;  STRING  (1..  CjSTRINC^LENGTH) ; 

bagin  —  block 

--  copy  tha  string  from  C  storaga  to  Ada  storaga 
ADA^STRING  ;»  READ_STR.all  (  1  ..  C_STRINC_LENCTH  ); 

--  print  tha  string 

TEXT_IO.PUT_LINE  ("Ada  raad:  "  k  ADA^STRINC  ); 
and;  —  block 
and  raad_cstring  ; 


B-73 


Implementation -Dependent  Characteristics 


F  14.3.4  Record  Types  and  HP  C  Subprograms 

For  more  information,  see  comments  on  general  parameter  passing  in  Section  F  14. 1.4.  Ada  records  may 
be  passed  as  parameters  to  external  interfaced  subprograms  written  in  HP  C  if  care  is  taken  regarding  the 
record  layout  and  access  to  record  discriminant  values.  See  Section  F  12  for  more  information  on  record 
type  layout 

Record  types  cannot  be  returned  as  function  results  from  external  interfaced  subprograms  written  in 
HPC 


F  14.3.5  Task  Types  and  HP  C  Subprograms 

Task  types  cannot  be  passed  as  procedure  or  function  parameters  in  HP  Ada.  Task  types  cannot  be 
returned  as  function  results  from  external  interfaced  subprograms  written  in  HP  C 


F  14.3.6  Private  Types  and  HP  C  Subprograms 

Private  types  cannot  be  passed  as  parameters  in  HP  Ada.  Private  types  cannot  be  returned  u  function 
results  from  external  interfaced  subprograms  written  in  HP  C 
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F  14.4  Calling  HP  FORTRAN  77  Language  Subprograms 

When  calling  interfaced  HP  FORTRAN  77  subprograms,  the  following  form  is  used: 

pragma  INTERFACE (FORTRAN,  Adajsubprogramjnanm) 

This  form  is  used  to  identify  the  need  for  HP  FORTRAN  77  parameter  passing  conventions. 

To  call  the  HP  FORTRAN  77  subroutine 

Subrout in*  FSUB  (Para) 

IntaQar*4  Pana 

•  a  a 

and 

you  need  this  interfaced  subprogram  declaration  in  Ada: 

procadura  FSUB  (PARM1  :  in  out  INTEGER); 
pragma  INTERFACE  (FORTRAN,  FSUB); 

The  external  name  specified  in  the  Ada  interface  declaration  can  be  any  Ada  identifier.  If  the  Ada 
identifier  differs  from  the  FORTRAN  77  subprogram  name,  pragma  INTERFACE_^NAME  is  required.  No 
special  handling  of  leading  underscores  is  required  as  this  is  handled  by  the  c^piler  to  conform  to 
standard  calling  conventions.  The  pragma  ensures  that  the  underscore  requir^  in  front  of  the 
HP  fortran  77  subroutine  name  is  correctly  inserted  by  the  compiler. 

Note  that  the  parameter  in  the  example  above  must  be  of  mode  IN  OUT.  In  HP  FORTRAN  77,  all  user 
parameters  mutt  be  passed  by  reference.  The  HP  FORTRAN  7?  compiler  creates  some  implicit 
parameters  that  are  passed  by  value  not  by  reference. 

Only  scalar  types  (integer,  floating  point,  boolean,  and  character  types)  are  allowed  for  the  result  returned 
by  an  external  interfaced  function  subprogram  writun  in  HP  FORTRAN  77.  Boolean  and  access  type 
results  are  not  supported. 

The  FORTRAN  libraries  llblTT.a  and  libFTT.a  are  required  when  linking  Ada  programs  that  contain 
external  interfaced  subprograms  written  in  FORTRAN  on  the  HP  9000  Series  300  impleroenution  of 
Ada.  This  may  be  done  by  including  the  following  options  in  the  ada(1)  command  line:  "-1177 
-1F77''.  Note  that,  unlike  the  optional  requirement  for  HP  C  interfaced  subprograms,  the 
HP  fortran  77  options  must  be  inserted  by  the  user.  The  eda  ( 1 )  mother  program  does  not 
automatically  search  the  HP  FORTRAN  77  libraries  as  the  program  searches  the  HP  C  librariea 

For  more  information,  see  the  following  manuals: 

•  FORTRAN/9000  Reference 

•  FORTRAN??  Programming  with  HP  Computers 

•  HP-UX  Portability  Guide 

For  general  information  about  passing  types  to  interfaced  subprograms,  see  Section  14. 1. 
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F  14.4.1  Scalar  Types  and  HP  FORTRAN  77  Subprograms 

This  lection  describes  considerations  when  passing  Kalar  types  between  Ada  programs  and  subprograms 
written  in  HP  FORTRAN  77.  Scalar  types  are  a  class  of  Ada  types  that  includes  integer,  real,  and 
enumeration  types.  Because  character  and  boolean  types  are  predefined  enumeration  types,  they  are  also 
scalar  types. 

All  Ada  scalar  type  parameters  are  passed  by  reference  to  FORTRAN  external  subprograma  Scalar  type 
parameters  therefore  must  be  declared  as  mode  IN  OUT  to  be  passed  by  reference. 

F  14.4.1.1  Integer  Types  and  HP  FORTRAN  77  Subprograms 

When  passing  parameters  to  an  HP  FORTRAN  77  language  subprogram,  all  scalar  parameters  (which 
includes  integer  parameters)  mutt  be  declared  as  IN  OUT  parameters  in  the  Ada  program  to  conform  to  the 
HP  FORTRAN  77  parameter  passing  conventions.  Then,  the  parameters  will  be  pased  by  reference.  A 
Sl-bit  address  pointer  to  the  integer  object  it  pushed  on  the  stack. 

Table  F-16  summarizes  the  correspondence  between  integer  types  in  HP  Ada  and  HP  FORTRAN  77. 


Table  F*16.  HP  Ada/HP  FORTRAN  77  Integer  Correspondence 


Ada 

HP  FORTRAN  77 

Bit  Length 

SHORT^SHORT_I NTECER 

no  equivalent  representation 

t 

8 

SHORT^INTECER 

INTEGER*! 

16 

INTEGER 

INTEGER*4 

32 

An  Ada  SHORT_SHORT_INTECCR  (stored  in  >  bits)  has  no  equivalent  integer  represenUtion  in 
HP  FORTRAN  77,  and  iT therefore  incompatible  with  any  HP  FORTRAN  77  integer  value.  Ada  values 
of  type  SHORT_SHORT_INTECER  must  be  converted  to  a  longer  integer  type  before  being  passed  by 
reference  as  a  parameter  to  an  HP  FORTRAN  77  subroutine. 

The  compatible  types  are  the  same  for  procedures  and  functions.  Compatible  Ada  integer  types  are 
allowed  for  the  result  returned  by  an  external  interfaced  function  subprogram  written  in 
HP  FORTRAN  77. 

Ada  semantics  do  not  allow  parameters  of  mode  IN  OUT  to  be  passed  to  function  subprograms.  Therefore 
for  Ada  to  call  HP  FORTRAN  77  external  interfaced  function  subprograms,  each  scalar  parameter’s 
address  must  be  passed.  The  use  of  the  supplied  package  SYSTEM  facilitates  this  passing  of  the  object’s 
addresa  The  parameters  in  an  HP  FORTRAN  77  external  function  must  be  declared  as  in  the  example  on 
the  following  page: 
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Ada  daclaratlon 
with  SYSTEM; 

VAL1  ;  INTEGER;  —  a  scalar  typa 
VAL2  :  FLOAT  ;  --a  scalar  typa 
RESULT  :  INTEGER; 

function  FTNFUNC  (  PARM1,  PARM2  :  SYSTEM . ADDRESS )  return  INTEGER; 

The  external  function  must  be  called  from  within  Ada  as  followr 

RESULT  ;»  FTNFUNC  (VALrADDRESS.  VAL2 'ADDRESS ) ; 

Because  this  has  the  effect  of  obscuring  the  types  of  the  actual  parameter^  it  is  suggested  that  such 
declarations  be  encapsulated  within  an  INLINED  Ada  body  so  that  the  parameter  types  are  made  visible. 
An  example  follows: 

--  spaeif ication  of  function  to  ancapsulata 
function  FTNFUNC  (PARM1  :  INTEGER; 

PARM2  ;  FLOAT  )  return  INTEGER; 
pragma  INLINE  (FTNFUNC); 

with  SYSTEM; 

--  body  of  function  to  ancapsulata 
function  FTNFUNC  (PARM1  :  INTEGER; 

PARM2  :  FLOAT  }  return  INTEGER  is 
function  FORTFUNC  (PI,  P2  :  SYSTEM. ADDRESS)  return  INTEGER; 
pragma  INTERFACE  (FORTRAN,  FORTFUNC); 

begin  —  function  FTNFUNC 

return  FORTFUNC  (PARMI' ADDRESS,  PARM2 ' ADDRESS ) ; 
end  FTNFUNC; 


In  the  previous  example,  the  name  of  the  interfaced  external  function  subprogram  (written  in 
HP  FORTRAN  77)  is  FORTFUNC  This  name  is  declared  in  the  following  way: 

IntegareA  FUNCTION  FORTFUNC  (I,  X) 

Integers^  I 
Real*4  X 

see 

and 


F  14.4.1.2  Enumeration  Types  and  HP  FORTRAN  77  Subprograms 

The  HP  FORTRAN  77  language  does  not  support  enumeration  typea  However,  objects  that  are  elements 
of  Ada’s  enumeration  type  can  be  passed  as  INTEGER  as  the  underlying  integer  representation  of  the 
element.  Then,  those  objects  can  be  used  in  an  HP  FORTRAN  77  routine  as  INTEGER,  similar  to  the  way 
Ada  booleans  are  passed  (for  more  information,  see  the  following  section). 
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F  14.4.1.3  Boolean  Types  and  HP  FORTRAN  77  Subprograms 

In  HP  Ada,  the  type  BOOLEAN  is  represented  in  8  bits  and  cannot  be  used  as  a  logical  or  short  logical  (that 
is,  LOCICAL*2)  in  HP  FORTRAN  77.  However,  an  INTEGER  may  be  passed  instead  of  the  boolean  value 
(which  can  be  mapped  to  a  LOGICAL*2). 

Although  a  predefined  enumeration  type,  Ada  boolean  values  are  represented  in  8  bits  in  a  manner 
different  from  other  enumeration  types  in  the  HP  implementation  of  Ada  .  The  internal  representation 

of  FALSE  corresponds  to  2^0000 _ OOOChF  and  TRUE  corresponds  to  2^1 1 1 1 _ 1  111#  (that  is,  all  zeros  or 

all  ones  in  8  biu).  Note  that  the  value  of  BOOLEAN 'PCS  (TRUE)  is  1  and  the  value  of 
BOOLEAN 'P0S( FALSE)  is  a 

The  Ada  attribute  'POS  can  be  used  to  convert  an  Ada  boolean  to  an  integer  type,  which  can  then  be 
passed  to  an  HP  FORTRAN  77  external  subprogram.  Note  that  in  Ada,  BOOLEAN 'PCS (TRUE)  has  a 
result  of  (UNIVERSAL_INTECER)  one,  and  that  BOOLEAN 'POS(  FALSE)  has  a  result  of 
(UNIVERSAL_INTECER)  z»a  This  result  can  then  be  converted  to  an  integer  type  of  16  bits  and 
subsequently  can  be  treated  as  a  LOCICAL*2  in  HP  FORTRAN  77  and  passed  as  a  parameter. 

Likewise,  function  resulu  of  type  LOGICAL  from  an  HP  FORTRAN  77  function  subprogram  may  be 
considered  in  Ada  as  having  a  SHORT_INTEGER  type  representing  the  position  (attributo  'POS)  of  the 
equivalent  boolean  value. 

For  example,  an  HP  FORTRAN  77  subroutine  of  the  form 

SUBROUTINE  LOGICAL  SUB  (LOGICAL  PARK) 

LOCICAL*2  LOGICAL^PARM 

RETURN 

can  be  called  after  suiuble  declarations  in  Ada  as  follows: 

aubtypo  FORTRAN_LOCICAL  ia  SHORTJNTEGER;  —  16  bita 
BVAR  :  boolean';  --  will  ba  input  boolean  value 

--  define  a  place  holder  for  equivalent  integer 
BTEMP  ;  SHORT__INTECER;  —  integer  on  16  bita 

procedure  BOOL  PR0C(B  FARM  ;  in  out  FORTRAN  LOGICAL); 

pragma  INTERFACE  (FORTRAN,  BOOL  PROC); 

pragma  INTERFACE_NAME  (  BOOL^PROC,  L0CICAL_SUB) ; 

The  above  subroutine  is  called  from  the  Ada  program  as: 

BTEMP  :■  FORTRAN_LOClCAL(BOOLEAN'POS(B_VAR));  —  get  equivalent 
BOOL_PROC(  BTEMP  );  --  the  call  to  the  external 

"  aubroutine  LOGICAL  SUB 
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Note  that  the  expression 

BOOLEAN 'POS(B_VAR) 

evaluates  to  a  UNIVERSAL_INTECER  value  of  one  if  B_VAR  is  TRUE  or  a  UNIVERSAL_INTECER  value  of 
zero  if  B_^VAR  is  FALSE,  while  the  expression  of  the  form 

BTEMP  :«  FORTRAN^LOCICAL (...); 

is  an  explicit  type  conversion  (on  the  right)  and  assignment  to  a  1 6-bit  integer  type  (on  the  left)  that  is 
required  to  be  passed  to  map  into  an  equivalent  sized  HP  FORTRAN  77  L0GICAL*2  object. 

Note  that  the  call  from  the  Ada  program  in  the  preceding  example  involved  an  assignment  rather  than  an 
embedded  expression.  An  Ada  restriction  is  that  an  IN  OUT  parameter  must  not  be  an  expression.  So,  the 
following  example  is  not  legal  Ada: 

BOOL_PROC(FORTRAN_LOGICAL(BOOLEAN'POS(B_VAR)));  —  not  legal 


F  14.4.1.4  Real  Types  and  HP  FORTRAN  77  Subprograms 

This  section  discusses  passing  fixed  and  floating  point  types  to  subprograms  written  in  FORTRAN. 

Fixed  Point  Real  Types 

Ada  fixed  point  types  are  not  supported  at  parameters  or  at  results  of  external  interfaced  subprograms 
written  in  HP  FORTRAN  77.  Ada  fixed  point  types  cannot  be  returned  at  function  results  from  external 
interfaced  subprograms  written  in  HP  FORTRAN  77. 

a 

Floating  Point  Real  Types 

Parameters  of  type  FLOAT  in  Ada  correspond  to  the  default  REAL  (REAL*4)  format  in  HP  FORTRAN  77. 
The  Ada  type  LONC_FLOAT  is  equivalent  to  the  HP  FORTRAN  77  type  DOUBLE  PRECISION  (or  REALMS). 
HP  FORTRAN  77  follows  the  IEEE  P754  floating  point  conventions  for  both  32-bit  and  64-bit  floating 
point  numbers.  Both  32-bit  real  values  and  64-bit  real  values  can  be  passed  as  parameters. 

A  REAL  value  from  an  HP  FORTRAN  77  external  function  subprogram  may  be  returned  as  a  function 
result  of  type  FLOAT  in  an  Ada  program. 

A  DOUBLE  PRECISION  (or  REALMS)  value  from  an  HP  FORTRAN  77  external  function  subprogram  may 
be  returned  as  a  function  result  of  type  LONG_FLOAT  in  an  Ada  program. 

When  passed  as  parameters  to  an  interfaced  subprogram  written  in  HP  FORTRAN  77,  the  original  real 
values  are  not  altered  and  a  32-bit  address  of  the  real  object  is  pushed  on  the  stacL 
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F  14.4.2  Access  Types  and  HP  FORTRAN  77  Subprograms 

Ada  access  types  have  no  meaning  in  HP  FORTRAN  77  subprograms  because  the  types  are  address 
pointers  to  Ada  objects.  The  implementation  value  of  an  Ada  parameter  of  type  ACCESS  may  be  passed  to 
an  HP  FORTRAN  77  procedure.  The  parameter  in  HP  FORTRAN  77  is  seen  as  INTEGER* 4.  The  object 
pointed  to  by  the  access  parameter  has  no  significance  in  HP  FORTRAN  77;  its  value  would  be  useful 
only  for  comparison  operations  to  other  access  values. 

Parameten  or  function  results  of  type  ACCESS  from  external  interfaced  subprograms  written  in 
HP  FORTRAN  77  are  not  supported.  HP  FORTRAN  77  could  return  an  INTEGER  and  the  Ada  program 
can  use  as  the  returned  value  type  INTEGER  (a  matching  size,  because  HP  Ada’s  INTEGER  it  a  32*bit 
quantity  in  this  implementation).  The  significance  and  use  in  HP  FORTRAN  77  of  such  a  value  must  be 
understood  as  meaningless,  as  mentioned  previously. 


F  14.4.3  Array  Types  and  HP  FORTRAN  77  Subprograms 

For  more  information,  see  the  general  comments  on  parameter  passing  of  arrays  in  Section  F  14. 1. 3. 

Arrays  whose  components  have  an  HP  FORTRAN  77  representation  can  be  passed  as  parameters  between 
Ada  and  interfaced  external  HP  FORTRAN  77  subprograms.  For  example,  Ada  arrays  whose  components 
are  of  types  INTEGER,  SHORT^INTEGER,  FLOAT,  LONG_rLOAT,  or  CHARACTER  may  be  passed  as  parameters. 
Arrays  are  not  supported  as  function  results  from  external  HP  FORTRAN  77  function  subprograms. 


CAUTION 


Arrays  with  multiple  dimensions  are  implemented  differently  in  Ada  and 
HP  FORTRAN  77.  To  obuin  the  same  layout  of  componenu  in  memory  as 
a  given  HP  FORTRAN  77  array,  the  Ada  equivalent  must  be  declared  and 
used  with  the  dimensioiu  in  reverse  order. 


Consider  the  components  of  a  I-row  by  3’^lumn  matrix,  declared  in  HP  FORTRAN  77  an 

INTECER*4  A(2,3)  OR  INTECER*4  A(1:2,1:3) 

This  array  would  be  stored  by  HP  FORTRAN  77  in  the  following  order 

A(1,1),  A(2.1),  A(1,2).  A(2,2).  A(1,3),  A(2,3) 

This  is  referred  to  u  storing  in  column  major  order,  that  is,  the  first  subscript  varies  most  rapidly,  the 
second  varies  next  most  rapidly,  and  so  forth,  and  the  last  varies  least  rapidly. 

Consider  the  components  of  a  2 -row  by  3-column  matrix,  declared  in  Ada  as: 

A  ;  array  (1..2,  1..3)  of  INTEGER; 

This  array  would  be  stored  by  Ada  in  the  following  order 

A(1,1),  A(1,2),  A(1,3),  A(2,1),  A(2,2),  A(2,3) 
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This  it  referred  to  at  storing  in  row  major  order,  that  it  the  last  subscript  varies  most  rapidly;  the  next  to 
last  varies  n'txt  most  rapidly,  and  so  forth,  while  the  first  varies  least  rapidly.  Clearly  the  two  declarations 
in  the  different  languages  are  not  equivalent  Now,  consider  the  components  of  a  2-row  by  3-column 
matrix,  declared  in  Ada  as; 

A  :  army  (1..3.  1,.2)  of  INTEGER; 

Note  the  reversed  subscripts  compared  with  the  FORTRAN  declaration.  This  array  would  be  stored  by 
Ada  in  the  following  order 

A(1,1).  A(1,2),  A(2,l),  A(2,2).  A(3,l).  A(3.2) 

If  the  subscripts  are  reversed,  the  layout  would  be 

A(1,1),  A(2,1),  A(1,2).  A(2,2),  A(l,3).  A(2,3) 

which  is  identical  to  the  HP  FORTRAN  77  layout  Thus,  either  of  the  language  declarations  could  declare 
its  component  indices  in  reverse  order  to  be  compatible. 

To  illustrate  that  equivalent  multidimensional  arrays  require  a  reversed  order  of  dimensions  in  the 
declarations  in  HP  FORTRAN  77  and  Ada,  consider  the  followinr 

The  Ada  statement 

FOO  :  array  (1 . . 10.1 , .5.1 . .3)  of  FLOAT; 

is  equivalent  to  the  HP  FORTRAN  77  declaration:  ^ 

REAL*4  FOO(3.S.10) 

Or 

REAL«4  FOO(1;3. 1:5. 1:10) 

Both  Ada  and  HP  FORTRAN  77  store  a  one-dimensional  array  u  a  linear  list 


F  14.4.4  String  Typ«s  and  HP  FORTRAN  77  Subprograms 

When  a  string  item  is  passed  as  an  argument  to  an  HP  FORTRAN  77  subroutine  from  within 
HP  fortran  77,  extra  information  is  transmitted  in  hidden  (implicit)  parametert  The  calling  sequence 
includes  a  hidden  parameter  (for  each  string)  which  is  the  actual  length  of  the  ASCII  character  sequence. 
This  implicit  parameter  is  passed  in  addition  to  the  address  of  the  ASCII  character  string.  The  hidden 
parameter  is  passed  by  value,  not  by  reference. 

These  conventions  are  different  from  those  of  Ada.  For  an  Ada  program  to  call  an  external  interfaced 
subprogram  written  in  HP  FORTRAN  77  with  a  string  type  parameter,  you  must  explicitly  pass  the 
length  of  the  string  object  The  length  must  be  declared  as  an  Ada  32-bit  integer  parameter  of  mode  IN. 

The  following  example  illustrates  the  declarations  needed  to  call  an  external  subroutine  having  a 
parameter  profile  of  two  strings  and  one  floating  point  variable. 
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proccdur*  FTNSTR  it 
SA;  STRINC(1..6) 
SB:  STRINC(1..2) 
FLOAT  VAL:  FLOAT 


“ABCDEF"; 

"GH"; 

1.5; 


LENCTH_SA,  LENCTH_SB  :  INTEGER; 


proctduPt  FEXSTR  (  SI  ;  STRING; 

F  :  in  out  FLOAT;  —  mutt  bt  IN  OUT 

S2  :  STRING;  ttringt  tr#  pttttd  by  rtftrtnct 

LS2  :  in  SHORT__INTECER;  —  Itn  of  ttring  S2, 

--  mutt  bt  IN 

LSI  :  in  SHORTJNTECER  );  --  Itn  of  ttring  SI, 

—  mutt  bt  IN 


pragma  INTERFACE  (FORTRAN.  FEXSTR); 


btgin  —  proetdurt  FTNSTR 
LENGTH  SA  :■  SA' LENGTH; 

LENGTh”SB  :■  SB' LENGTH; 

FEXSTRTsA,  float  VAL,  SB.  LENGTH  SA,  LENGTH  SB); 
tnd  FTNSTR;  "  " 


NOTE 


Note  that  the  order  of  the  ttring  lengths  it  in  the  tame  order  of  their 
appearance  in  the  corresponding  parameter  and  tlut  they  appear  afur  all 
other  parameters  (at  the  end  of  the  parameter  list).*  The  ttring  lengths  must 
be  pasted  by  value,  not  by  reference. 


The  HP  FORTRAN  77  external  subprogram  it  the  following: 

SUBROUTINE  FEXTR  (Si,  r,  S2) 

CHARACTER  •(♦)  SI,  S2 
REAL*4  r 
•  •  • 

END 


NOTE 


HP  Ada  does  not  allow  a  ttring  type  (constrained  or  nor)  to  be  returned 
from  a  function  interfaced  with  HP  FORTRAN  77.  Thus,  it  it  not  possible 
to  declare  an  Ada  external  function  that  returns  a  result  of  type  STRING 
(type  STRING  is  an  object  of  type  CHARACTER  *(*)  in  HP  FORTRAN  77). 
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F  14.4.5  Record  Types  and  HP  FORTRAN  77  Subprograms 

There  are  no  record  types  in  HP  FORTRAN  77.  Record  types  cannot  be  passed  at  parameters  in 
HP  FORTRAN  77.  Function  results  of  type  RECORD  from  external  interfaced  subprograms  written  in 
HP  FORTRAN  77  are  not  supported. 


F  14.4.6  Task  Types  and  HP  FORTRAN  77  Subprograms 

Task  types  cannof  be  passed  at  procedure  or  function  parameters  in  HP  Ada.  Function  results  of  type 
TASK  from  external  interfaced  subprograms  written  in  HP  FORTRAN  77  are  nor  supported. 


F  14.4.7  Private  Types  and  HP  FORTRAN  77  Subprograms 

Private  types  cannot  be  paned  at  parameters  in  HP  Ada.  Function  results  of  type  PRIVATE  from  external 
interfaced  subprograms  written  in  HP  FORTRAN  77  are  nor  supported. 


F  14.4.8  Other  FORTRAN  Types 

The  HP  FORTRAN  77  types  COMPLEX,  COMPLEX*B,  DOUBLE  COMPLEX,  and  COMPLEX*  16  have  no  direct 
counterparts  in  Ada.  However,  it  is  possible  to  declare  equivalent  types  using  either  an  Ada  array  or  an 
Ada  record  type.  For  example,  with  type  COMPLEX  in  HP  FORTRAN  77,  a  simple  Ada  equivalent  is  a 
user -defined  record: 

type  COMPLEX  ia  rocord 
Roal  ;  FLOAT  :•  0.0; 

Imag  :  FLOAT  :•  0.0; 

•nd  record; 

Similarly,  an  HP  FORTRAN  77  double  complex  number  could  be  represented  with  the  two  record 
components  declared  as  Ada  type  LONC^FLOAT. 

While  it  is  not  posible  to  declare  an  Ada  external  function  that  returns  such  a  complex  type,  an  Ada 
procedure  can  be  declared  whose  first  OUT  parameter  is  of  type  COMPLEX.  The  Ada  procedure  would  have 
the  same  functionality  as  the  HP  FORTRAN  77  function,  with  a  different  mechanism  for  returning  the 
result 
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F  14.5  Calling  HP  Pascal  Language  Subprograms 

Calling  external  interfaced  Pascal  language  subprograms  from  Ada  programs  requires  the  use  of  the 
assembly  language  routines  8sm_initproc  and  asm_wrapup.  Calls  to  these  procedures  must  bracket  the 
program  containing  calls  to  Pascal  routines,  but  only  one  call  to  each  of  these  routines  is  required  per 
program. 

The  first  of  these  calls  must  be  made  to  set  up  Pascal  file  system,  the  Pascal  heap  manager,  and  error 
recovery  (for  the  Pascal  procedures),  and  the  second  to  cleanup  from  the  heap,  the  file  system  and  error 
recovery  usage  that  was  set  up  by  the  previous  caU.  Without  placing  these  calls  as  required  the  program 
behavior  may  be  erroneous  or  unpredicuble.  For  more  information  on  Pascal  interfacing,  see  the  HP 
Pascal  Li-nguaft  Reference  Manual,  and  the  section,  HP-UX  Implementation,  Pascal  and  other 
Languages*.  Additional  information  is  available  in  the  HP-UX  Portability  Guide. 

Another  unusual  aspect  of  calling  Pascal  subprograms  (functions  and  procedures)  is  that  these  routines 
cannot  be  compiled  separately  in  Pascal  unless  enclosed  in  a  module  declaration.  The  consequence  of  this 
is  that  the  name  of  the  module  is  prepended  to  the  procedure  or  function  name  with  an  underscore 
character  separating  the  two  identifiert  This  is  done  by  the  Pascal  compiler,  and  needs  to  be  taken  into 
account  in  the  Ada  calling  program  in  the  pragma  INTERFACE  declaration. 

For  an  external  interfaced  Pascal  subroutine: 

modulo  modp: 
export 

proctduro  aubr  (var  parm  :  intogor); 

Implomont 

proctduro  aubr. (var  parm  :  intogor);* 
bagin 

too 

ond  ; 
ond. 

Note  the  name  of  the  Pascal  external  subprogram  as  viewed  externally  (from  Ada)  includes  module  name 
modp  and  the  procedure  name  aubr  formed  into  the  single  identifier  modp_aubr.  We  would  reqtxire  the 
following  interfaced  subprogram  declarations  in  Ada: 

typo  ochojRiodo  is  accoaa  INTEGER; 

proctduro  MODP  SUBR  (Parmi  :  in  INTEGER); 
pragma  INTERFACE  (Pascal,  MODP^SUBR); 

proctduro  aam^initproc  (ocho  :  ocho_modo  ); 
pragma  INTERFACE(ASSEMBLER,  aaffl__^initproc} ; 

proctduro  asm^wrapup; 

pragma  INTERFACE(AS5EMBLER,  asm  wrapup); 
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to  call  the  external  Pascal  subprogram  : 

apam  :  INTEGER  :«  0; 

•cho  :  •cho_fflod«  :•  new  INTEGER '(O); 
noecho  :  echo_fflode  :»  new  INTEGER' (1); 

aem_initproc{echo};  --  Initlalixe  heap,  etc 

e  e  e 

M00P_SUBR  (aparm);  --  the  call  to  Pascal  procedure 


asm__wrapup;  --  cleanup 


For  Pascal,  scalar  and  access  parameters  of  mode  IN  are  passed  by  value:  the  value  of  the  parameter 
object  is  copied  and  pushed  on  the  staclL  All  other  types  of  IN  parameters  (arrays,  records),  and 
parameters  of  mode  OUT  and  IN  OUT  are  passed  by  reference:  The  address  of  the  object  is  pushed  on  the 
stack.  This  means  that  in  general  Ada  IN  parameters  correspond  to  Pascal  value  parameters  while  Pascal 
VAR  parameters  correspond  to  the  Ada  parameters  of  either  mode  IN  OUT  or  mode  OUT. 

For  Pascal  external  interfaced  subprograms  called  from  an  Ada  program,  all  parameters  are  passed  in 
containers  of  size  32-bits,  except  for  Ada  LONG^FLOAT  parameters  which  are  paiUd  in  64-bita 

Only  scalar  types  (integer,  floating  point,  character.  Boolean,  and  enumeration  types)  and  access  types  are 
allowed  for  the  result  returned  by  an  external  interfaced  Pascal  function  subprograms. 


For  general  information  about  passing  parameters  to  interfaced  subprograms,  see  Section  14. 1. 


t- 
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F  14.S.1  Scalar  Types  and  HP  Pascal  Subprograms 

This  section  discusses  passing  scalar  types  between  Ada  programs  and  subprogram  written  in  HP  Pascal 
Scalar  types  include  integer,  real,  and  enumeration  types.  Because  character  and  boolean  types  are 
predefined  enumeration  types,  they  are  also  scalar  types. 

Ada  scalar  type  parameters  of  mode  IN  are  passed  by  value.  Scalar  type  parameters  of  mode  OUT  or 
IN  OUT  are  passed  by  reference. 


F  14.5.1.1  Integer  Types  and  HP  Pascal  Subprograms 

Integer  types  are  compatible  between  Ada  and  HP  Pascal  provided  their  ranges  of  values  are  identical 
Table  F-1 7  shows  corresponding  integer  types  in  Ada  and  HP  Pascal 


Table  F*17.  Ada/HP  Pascal  Integer  Correspondence 


Ada 

HP  Pascal 

Bit  Length 

predefined  INTEGER 

predefined  INTEGER 

32 

predefined  SHORT_^INTEGER 

user-defined  types 
type  116— 32768...  32767; 

16 

predefined  SHORT^SHORT^INTEGER 

user-defined  type , 
type  18- -128...  127; 

8  (Ada) 

16  (Pascal) 

When  passed  by  value  to  an  HP  Pascal  language  subprogram,  all  integer  values  are  extended  to  32  bits  to 
conform  to  the  HP  Pascal  parameter  pasting  conventions.  Ada  INTEGER  (32  bits)  types  passed  by  value 
are  pushed  onto  the  suck  without  alteration.  Values  of  type  SHORT_SHORT_INTECER  (8  bits)  and  type 
SHORT_INTECER  (16  bits)  are  sign  ezUnded  to  32  bits  and  pu^ed  on  the  stack. 

When  passed  by  reference,  the  integer  values  are  not  changed;  the  original  values  are  not  sign  extended  to 
32  bits.  A  32'bit  addren  pointer  to  the  integer  object  is  pushed  on  the  sUck. 

When  passing  integers  by  reference,  note  that  the  predefined  Ada  SHORT^INTECER  (stored  in  16  bits)  and 
the  Ada  SHORT_SNORT_INTECER  (stored  in  8  bits)  have  no  equivalent  pr^efined  integer  representations 
in  HP  Pascal  However7 an  HP  Pascal  integer  can  be  declared  whose  range  matches  the  range  of  these 
types.  Note  that  a  difference  in  data  layout  between  the  two  languages  for  the  range  -128  through  127 
places  a  restriction  on  passing  a  SHORT_SHORT^INTECER  to  Pascal  For  example,  the  range  and  storage 
size  of  Ada’s  SHORT^INTECER  corresponds  to  the  range  and  storage  size  of  HP  Pascal  declaration 

type  116  >  -32768  ..  32767  ; 

The  range  of  Ada’s  SHORT^SHORT_INTECER  corresponds  to  the  range  of  HP  Pascal  declaration 
type  18  ■  -128  . .  127  ; 

However,  the  storage  size  is  1 6  bits  in  HP  Parcal  while  it  is  8  bits  in  Ada. 
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All  Ada  integer  types  are  allowed  for  the  result  returned  by  an  external  interfaced  subprogram  written  in 
HP  Pascal,  if  care  is  taken  with  respect  to  ranges  defined  for  integer  quantities.  The  automatic  sign 
extension  helps  in  passing  dissimilar-sized  values  that  are  within  an  acceptable  range. 


F  14.5.1.2  Enumeration  Types  and  HP  Pascal  Subprograms 

Ada  and  HP  Pascal  have  different  implementations  of  enumeration  types.  As  Ada  enumeration  type 
when  passed  as  a  parameter  is  treated  as  if  it  were  the  underlying  integer  representation.  That  value  is 
either  an  8-bit  quantity  (for  enumeration  sizes  <■  128)  or  a  16-bit  quantity  (for  enumeration  sizes  > 
128).  It  is  passed  according  to  the  convention  given  above  for  integer  values.  When  passed  by  value,  the 
integer  is  copied  to  the  stack  and  automatically  extended  to  32  bits.  In  HP  Pantal,  all  enumeration  types 
are  16-bit  quantities,  regardless  of  enumeration  size.  If  care  is  taken  with  respect  to  the  underlying 
representation,  the  automatic  extension  to  32  bits  allows  the  two  implementations  to  treat  enumeration 
types  as  equivalent 

When  paned  by  reference,  the  original  value  is  not  altered  by  sign  extension  and  a  32-bit  addren  pointer 
to  the  enumeration  object  is  pushed  on  the  stack. 

Ada  supports  the  return  of  a  function  result  that  is  an  enumeration  type  from  an  external  interfaced 
function  subprogram  written  in  HP  Pascal 


F  14.5.1.3  Boolean  Types  and  HP  Pascal  Subprograms 

Although  a  predefined  enumeration  type,  Ada  boolean  values  are  represented  in  8  bits  in  a  manner 
different  from  other  enumeration  types  in  the  HP  implemenution  of  Ada  .  The  internal  represenution 
of  FALSE  corresponds  to  2#0000__0000<F  and  TRUE  corresponds  to  2#1 1 1 1_1 11 1#  (that  is,  all  zeros  or 
all  ones  in  8  bits).  Note  that  the  value  of  BOOLEAN 'PPS (TRUE)  it  1  and  the  value  of 
BOOLEAN '  POS( FALSE)  is  0.  Since  HP  Pascal  treats  boolean  values  differently,  an  Ada  boolean  value  may 
not  be  treated  as  a  Pascal  boolean  value  in  an  external  subprogram,  whether  passed  by  value  or  pasted  by 
reference.  The  Ada  attribute  POS  can  be  used  to  convert  an  Ada  boolean  type  to  an  integer  type. 

There  is  no  support  for  the  return  of  a  function  result  that  is  a  boolean  type  from  an  external  interfaced 
function  subprogram  written  in  HP  Pascal 


F  14.5.1.4  Character  Types  and  HP  Pascal  Subprograms 

Values  of  the  Ada  predefined  character  type  may  be  treated  u  the  type  char  in  HP  Pascal  external 
interfaced  subprograma  Both  the  Ada  and  HP  Pascal  types  occupy  8  bits  and  have  the  tame  internal 
representation. 

Character  types  are  represented  as  8  bits  in  the  HP  implemenution  of  Ada.  When  passed  by  value  to  an 
interfaced  subprogram  written  in  HP  Pascal  values  of  type  CHARACTER  are  extended  to  32  bits  and 
pushed  on  the  stack;  the  actual  value  is  the  low-order  (rightmost)  8  bit. 

When  passed  by  reference  to  an  interfaced  subprogram  written  in  HP  Pascal  the  character  values  are  not 
altered  and  a  32-bit  add-ess  of  the  character  object  is  pushed  on  the  suck. 

Ada  character  values,  whether  passed  by  value  or  reference  to  HP  Pascal  can  be  used  directly  by  the 
interfaced  subprogram  as  values  of  type  char. 
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Ada  supports  the  return  of  a  function  result  that  is  a  character  type  from  an  external  interfaced  function 
subprogram  written  in  HP  Pascal  The  HP  Pascal  result  is  of  type  char  while  the  Ada  result  it  of  type 
CHARACTER. 


F  14.5.1.5  Real  Types  and  HP  Pascal  Subprograms 

The  following  subsections  discuss  passing  Ada  real  types  to  interfaced  HP  Pascal  subprograms. 

Fixed  Point  Types 

Ada  fixed  point  types  are  not  supported  at  parameters  or  as  results  of  external  subprograms  Ada  fixed 
point  types  cannot  be  returned  as  function  results  from  interfaced  subprograms  written  in  HP  Pascal. 

Floating  Point  Real  Types 

HP  Pascal  uses  the  IEEE  P7S4  (draft  10.0)  floating  point  conventions  for  both  32-bit  and  64-bit  floating 
point  numbers.  Ada  FLOAT  values  correspond  to  HP  Pascal  REAL  values  Ada  LONC_FLOAT  values 
correspond  to  HP  Pascal  LONCREAL  values 

In  HP  Pascal  32-bit  real  values  are  not  automatically  extended  to  64-bit  values  when  passed  u 
parameters  between  external  interfaced  subprograms  written  in  HP  Pascal  and  an  Ada  program.  Both 
32-bit  and  64-bit  real  types  can  be  returned  as  results  from  an  external  interfaced  function  subprogram 
written  in  HP  Pascal 

When  passed  by  value  to  interfaced  subprograms  written  in  HP  Pascal  values  of  type  FLOAT  and 
LONG^FLOAT  are  copied  and  pushed  on  the  stack.  Float  values  of  32  bits  are  not  automatically  extended 
to  64l>its  when  passed  by  value. 

# 

When  passed  by  reference  to  an  interfaced  subprogram  written  in  HP  Pascal  the  original  values  are  not 
altered  and  a  32-bit  address  of  the  object  is  pushed  on  the  stack. 


F  14.5.2  Access  Types  and  HP  Pascal  Subprograms 

Ada  access  values  can  be  treated  as  pointer  values  in  HP  Pascal  external  interfaced  subprograms  because 
they  are  address  pointers  to  Ada  objecta  The  Ada  allocation  and  the  HP  Pascal  allocation  are  completely 
separate.  There  must  be  no  explicit  reallocation  in  one  language  of  an  object  allocated  in  the  other 
langxuge. 

An  object  designated  by  an  Ada  access  type  can  be  passed  to  a  HP  Pascal  external  subprogram,  subject  to 
rules  applicable  to  the  type  of  the  underlying  object. 

Ada  access  types  of  mode  IN  are  passed  by  value.  When  an  access  type  is  psissed  by  value,  a  copy  of  the 
'2-bit  object  address  is  pushed  on  the  stack.  If  the  type  is  passed  by  reference,  however,  a  32-bit  address 
p  inter  to  the  object  address  location  is  pushed  on  the  sucIl  This  is  effectively  a  double  indirect  address 
to  the  underlying  object  (See  Figure  F-1  in  Section  F  14. 1.2.) 

Ada  access  types  may  be  returned  as  function  results  from  external  interfaced  subprograms  written  in 

HP  Pascal 


i 
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F  14.5.3  Array  Types  and  HP  Pascal  Subprograms 

Arrays  with  components  with  the  same  representation  have  the  same  representation  in  Ada  and 
HP  Pascal 

Arrays  cannot  be  passed  by  value  from  Ada  to  HP  Pascal  Only  the  passing  of  arrays  declared  as  a  VAR 
parameter  in  an  HP  Pascal  subprogram  to  an  Ada  program  is  supported. 

Array  types  cannot  be  returned  as  function  results  from  external  interfaced  subprograms  written  in 
HP  Pascal 

Note  that  the  function  results  of  array  types  are  not  supported  between  HP  Pascal  and  Ada. 
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F  14.5.4  String  Types  and  HP  Pascal  Subprograms 

Passing  variable  length  strings  between  Ada  and  HP  Pascal  is  supported  with  some  restrictiona  The 
parameters  must  be  passed  by  reference  only.  HP  Pascal  programs  must  declare  VAR  parameters  and  the 
Ada  program  must  declare  the  parameters  to  be  of  mode  IN  OUT  or  OUT  to  ensure  passing  by  reference. 

Although  there  is  a  difference  in  the  implementation  of  the  type  STRING  in  the  two  languages,  with 
euitable  declarations  you  can  create  compatible  types  to  allow  the  passing  of  both  Ada  strings  and 
HP  Pascal  stringa  An  Ada  string  corresponds  to  a  packed  array  of  characters  in  Pascal  The  following 
example  illustrates  the  declaration  of  compatible  types  for  passing  an  Ada  string  between  an  Ada  program 
amd  an  HP  Pascal  subprogram. 

HP  Pascal  subprogram: 

—  passing  an  Ada  STRING  typa  to  an  HP  Pascal  routlna  — 
module  p; 
export 

type  stringSO  «  packed  array  [1..80]  of  char; 
procedure  exi  (  var  a  :  stringSO;  len  :  integer  ); 
implement 

procedure  exi; 
begin 

...  (•  update/use  the  Ada  string  as  a  PAC  •) 
end; 
end. 


Ada  program: 

—  Ada  calling  HP  Pascal  procedure  with  Ada  STRING 
procedure  AP_1  is 

--  Define  Ada  string  corresponding  to  HP  Pascal  packed  array  of  char 
subtype  STRINGSO  is  STRING  (  1..80  }; 


—  Ada  definition  of  HP  Pascal  procedure  to  be  called,  with  an 

—  Ada  STRING  parameter,  passed  by  reference, 

procedure  P^EXI  (S  :in  out  STRINGSO; 

LEN  :  integer  ); 

pragma  INTERFACE  (PASCAL,  P  EXI); 


—  Define  the  HP  Pascal  initialization  routine  interfaces 
procedure  Pstart  (  argc  :  INTEGER;  argv  :  STRING  ); 
pragma  INTERFACE  (ASSEMBLER,  Pstart  ); 

pragma  INTERFACE_NAME  (  Pstart,  **  Pstart**  );  —two  underscores 
~  —are  required 


S  :  STRINGSO; 


begin  --  AP^I 

Pstart  (  0,  '**'  );  —  initialize  HP  Pascal  environment 
S(1..23)  :«  "Ada  to  HP  Pascal  Interface"; 

P^EXI  (S,  23);  —  Call  the  HP  Pascal  subprogram 

end  AP  1 ; 
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An  HP  Pascal  STRING  type  corresponds  to  a  record  in  Ada  that  contains  two  fields;  an  integer  field 
containing  the  string  length,  and  an  Ada  STRING  field  containing  the  string  value.  The  following 
example  illustrates  the  declaration  of  compatible  types  for  passing  an  HP  Pascal  string  between  an  Ada 
program  and  a  Pascal  subprogram. 

Pascal  subprogram: 

--  passing  an  HP  Pascal  STRING  type  from  Ada  to  an  HP  Pascal  routine 

fflodula  p; 

export 

type  stringBO  •  string  [80]; 
procedure  ex2  (  var  s  :  stringSO  ); 
implement 

procedure  ex2; 
var 

str  :  stringSO  ; 
begin 

...  --update/use  the  HP  Pascal  string 
end; 
end. 

Ada  program: 

--  Ada  calling  HP  Pascal  procedure  with  HP  Pascal  STRING 
procedure  AP_2  is 

-•  Define  Ada  string  corresponding  to  HP  fascal  packed  array  of  char 
type  PASCAL_STRING80  is 
record  ” 

LEN  :  INTEGER; 

S  :  STRING  (  1..e0  ); 
end  record; 

—  Ada  definition  of  HP  Pascal  procedure  to  be  called,  with  a 
—  HP  Pascal  STRING  parameter,  passed  by  reference, 
procedure  P  EX2  (S:in  out  PASCAL  STRINGSO); 
pragma  INTERFACE  (PASCAL,  P_EX2);" 

--  Define  the  HP  Pascal  initialixation  routine  interfaces 
procedure  Pstart  (  argc  :  INTEGER;  argv  :  STRING  }; 
pragma  INTERFACE  (ASSEMBLER,  Pstart  ); 

pragma  INTERFACE_NAME  (  Pstart,  *'  Pstart"  );  --  two  underscores 
PS  ;  PASCAL_STRING80; 
begin  --  AP_2 

Pstart  (  0,  ""  );  —  initialize  HP  Pascal  environment 
PS.S(1..23)  :■  "Ada  to  HP  Pascal  Interface";  —  assign  value  field 
PS. LEN  :«  23;  --  set  string  length  field 

P_EX2  (  PS  );  --  call  the  HP  Pascal  subprogram 

end  AP  2; 
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F  14.5.5  Record  Types  and  HP  Pascal  Subprograms 

See  the  comments  on  general  parameter  passing  in  Section  F  14. 1.4. 

Records  cannot  be  passed  by  value  from  Ada  to  HP  Pascal  Only  the  passing  of  records  declared  at  VAR 
parameters  in  the  HP  Pascal  subprogram  to  Ada  programs  is  supported.  The  record  is  passed  by  reference. 

Record  types  cannot  be  returned  as  function  results  from  external  interfaced  subprograms  written  in 
HP  Pascal 

F  14.5.6  Task  Types  and  HP  Pascal  Subprograms 

Task  types  cannot  be  passed  at  parameters  in  Ada.  Task  types  cannot  be  returned  as  function  results  from 
external  interfaced  subprograms  written  in  HP  PascaiL 

F  14.5.7  Private  Types  and  HP  Pascal  Subprograms 

Private  types  cannot  be  passed  as  parameters  in  Ada,  and  private  types  cannot  be  returned  as  function 
results  from  external  interfaced  subprograms  written  in  HP  Pascal 
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F  14.6  Summary 

Table  F-1 8  shows  how  various  Ada  types  are  passed  to  subprograms. 

Tabic  F-18.  Modes  for  Passing  Parameters  to  Interfaced  Subprograms 


Ada  Type 

Mode 

Passed  By 

ACCESS, 

SCALAR 

-INTEGER 

-ENUMERATION 

-boolean 

-CHARACTER 

-REAL 

IN 

value 

ARRAY. 

RECORD 

IN 

reference 

all  types  except  TASK, 
private,  and  FDCED 
POINT  REAL 

IN  OUT 

reference 

all  types  except  TASK, 
private,  and  HXED 
POINT  REAL 

OUT 

reference 

• 

TASK 

private 

FDCED  POINT  REAL 

N/A 

not  passed 
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Table  F-19  summarizes  general  information  presented  in  Section  14. 1. 

Table  F-19.  Types  Returned  as  External  Function  Subprogram  Results 


Ada  Type 

HP  Assembly 
Language 

HPC 

HP  FORTRAN 

HP  Pascal 

INTEGER 

allowed 

allowed 

allowed 

allowed 

ENUMERATION  1 

allowed 

allowed 

allowed 

CHARACTER 

allowed 

allowed 

not  allowed 

allowed 

BOOLEAN 

allowed 

allowed 

not  allowed 

REAL  FIXED 

not  allowed 

not  allowed 

not  allowed 

not  allowed 

REAL  FLOAT 

allowed 

allowed 

allowed 

ACCESS 

allowed 

allowed 

not  allowed^ 

allowed 

ARRAY 

not  allowed 

not  allowed 

not  allowed 

not  allowed 

RECORD 

not  allowed 

not  allowed 

not  allowed 

not  allowed 

TASK 

>  not  allowed 

not  allowed 

not  allowed 

not  allowed 

PRIVATE 

not  allowed 

not  allowed 

not  allowed 

not  allowed 

Notes  for  Table  F-19. 

2  Pass  as  an  integer  equivalent 

Some  restrictions  apply  to  Ada  FLOAT  types  (in  passing  to  HP  C  subprograms). 
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Table  F-20  summarizes  information  presented  in  Sections  F  14. 2  through  F  1 4.  5. 


Table  F-20.  Parameter  Passing  in  the  Series  300  Implementation 


Ada  Type 

HP  Assembly 
Language 

HPC 

HP  FORTRAN 

HP  Pascal 

INTEGER 

allowed 

allowed 

allowed 

allowed 

ENUMERATION 

allowed 

allowed 

allowed 

CHARACTER 

allowed 

allowed 

allowed 

allowed 

BOOLEAN 

allowed 

allowed 

REAL  FLOAT 

allowed 

allowed 

allowed 

allowed 

REAL  FIXED 

not  allowed 

not  allowed 

not  allowed 

not  allowed 

ACCESS 

allowed 

allowed 

not  allowed 

allowed 

iQQiim 

not  allowed 

allowed 

allowed 

STRING 

not  allowed 

aUowed 

RECORD 

not  allowed 

allowed 

allowed 

TASK 

not  allowed 

not  allowed 

not  allowed 

not  allowed 

PRIVATE 

not  allowed 

not  allowed 

not  allowed 

not  allowed 

_  Can  be  passed  at  an  equivalent  integer  value, 
f  Passed  by  value  only. 

^  Using  only  arrays  of  compatible  component  typea 
t  See  warning  on  layout  of  elements  in  section  for  each  language, 
f  Special  handling  of  null  terminator  character  is  required. 

”  Ada  strings  can  be  passed  to  a  Pascal  PAC  (Packed  Array  of  Characters) 
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F  14.7  Potential  Problems  Using  Interfaced  Subprograms 

The  Ada  run-time  executive  for  the  HP  9000  Series  300  computer  uses  signals  in  a  manner  that  generally 
does  not  interfere  with  interfaced  subprograms  However,  some  HP-UX  routines  are  interruptible  by 
signals  These  routines,  if  called  from  within  interfaced  external  subprograms,  may  create  problems  You 
need  to  be  aware  of  these  potential  problems  when  writing  external  interfaced  subprograms  in  other 
languages  that  will  be  called  from  within  an  Ada  main  subprogram.  See  eiov«ctor(2)  in  the  HP-UX 
Reftrtnee  for  a  complete  explanation  of  interruptibility  of  operating  system  routines 

The  following  should  be  taken  into  consideration: 

•  SICALRM  is  sent  when  a  DELAY  statement  is  being  timed. 

•  SICVTALRM  is  sent  when  round-robin  scheduling  is  used  in  tasking  programs 

•  There  are  "slow”  HP-UX  routines  (see  tlgv«etor(2})  that  can  be  interrupted  by  signals  generated  by 
the  Ada  run-time  executive.  Therefore  you  must  temporarily  block  these  signals  These  "slow"  routines 
include  HP-UX  I/O  calls  to  interactive  devices 

•  Ko  received  signals  will  be  lost  while  they  are  blocked,  owing  to  the  use  of  HP-UX  reliable  signals 

•  Any  signals  blocked  in  interfaced  code  must  be  unblocked  before  leaving  interfaced  code  to  return  to 
the  calling  Ada  program. 

The  Ada  run-time  executive  uses  two  time-related  signals  for  control  of  task  scheduling  and  the 
execution  of  DELAY  statements  The  executive  uses  SICALRM  to  indicate  the  end  of  a  DELAY  time  interval 
becau;-  -  SICALRM  operates  in  real  tims  The  run  time  uses  SICVTALRM  to  denote  the  end  of  a  task’s  time 
slice  amount,  because  SICALRM  operates  in  process-local  (virtual)  time. 

• 

These  two  signals  may  cause  problems  in  interfaced  routines  because  the  signals  are  asynchronous  to  the 
external  (interfaced)  cods  Asynchronous  in  this  context  means  that  the  signals  could  occur  at  any 
moment  and  they  are  not  caused  by  the  code  executing  at  the  instant  they  occur.  The  signals  may 
interrupt  some  vulnerable  routines  such  as  the  HP-UX  I/O  calls  mentioned  abo^ 

The  Ada  run-time  executive  for  the  HP  9000  Series  300  implementation  generates  and  catches  the 
following  HP-UX  signalc 

SICALRM  --  used  for  DELAY  statements 
SICVTALRM  --  used  for  task  scheduling 
SICSECV  —  STORAGE  ERROR 
SIOFPE  —  NUMERIC_ERROR,IUegaltrap 
SIGEMT  --  unimplemented  instruction 

SICBUS  --  PROGRAM  ERROR,  User  exception.  Illegal  trap,  Erroneous  instruction 
SICILL  —  CONSTRaTnT_ERROR,  NUMERIC^ERROR,  Ulegal  trap 

On  Ada  300,  the  signals  SICBUS,  SICSECV,  and  SICFPE  can  result  in  the  predefined  Ada  exceptions  listed 
above,  provided  their  associated  trap  number  (see  trapno  (2))  indicates  a  condition  defined  by  these 
exceptions.  You  should  not  attempt  to  modify  these  trap  conditions. 


B-96 


ImplemenUtion  -Dependent  Characterinict 


The  signals  SICALRM  and  SICVTALRM  are  not  always  generated  in  tasking 
programs.  SICALRM  is  only  generated  if  and  when  a  DELAY  statement  is 
encountered.  SICVTALRM  is  only  generated  if  time  slicing  has  not  been 
turned  off  with  the  binder  option  "-W  b,t,(r.  Non-tasking  programs  do 
not  use  SICVTALRM  because  for  such  programs  time  slicing  is  meaningless. 


Attempts  to  trap  or  ignore  any  of  the  signals  listed  above  (except  at  described  subsequently  and  in  section 
F  9. 1)  by  an  interfaced  subprogram  may  have  unpredictable  results:  Subprograms  that  are  part  of  the 
Ada  run-time  executive  are  the  only  exception;  however,  you  have  access  to  only  a  few  such  programs. 
See  the  Ada  User's  Guide  for  more  details. 

Problems  can  arise  if  an  interfaced  subprogram  initiates  a  '^low*  operating  system  function  that  can  be 
interrupted  by  a  signal  (for  example,  a  read  on  a  terminal  or  a  wait  for  a  child  proceu  to  complete). 
Problems  can  also  arise  if  an  interfaced  subprogram  can  be  called  by  more  than  one  task  and  is  not 
reentrant  If  an  Ada  reserved  signal  occurs  during  such  an  operation  or  non -reentrant  region,  the 
program  may  function  erroneously. 

For  example,  an  Ada  program  that  uses  DELAY  sutemenu  and  Usking  constructs  causes  the  generation  of 
SICALRM  and  SICVTALRM.  If  an  interfaced  subprogram  needs  to  perform  a  potentially  interruptible 
operating  system  call,  or  if  it  might  be  called  from  more  than  one  task  and  is  not  reentrant,  it  can  be 
protected  by  blocking  SICALRM  and  SICVTALRM  around  the  operating  system  call  or  non-reentrant 
region.  If  a  SICALRM  or  SICVTALRM  signal  signifying  either  the  end  of  a  delay  period  or  the  need  to 
reschedule  a  task  is  received  while  it  is  blocked,  the  signal  it  not  lost,  but  rather  deferred  until  it  is  later 
unblocked.  The  consequence  of  this  signal  blocking  is  that  Ada  task  scheduling  or  DELAY  statement 
execution  will  be  affected  for  the  duration  of  the  signal  blocL  * 

Here  is  an  example  of  a  protected  read  (2)  in  an  interfaced  subprogram  written  in  the  C  Language. 

#inelude  <algnal.h> 
void  interface  rout() 

( 

long  aesk; 


/•  Add  SICALRM  and  SICVTALRM  to  list  of  currently 
blocked  signals,  (see  sigblock(2) ) .  */ 

mask  «  sigblock  ((  1L  <<  (SICALRM-1))  |  (1L  <<  (SICVTALRM-1 ) ) ) ; 

...  reed  (...)  ;  /•or  non  reentrant  region  •/ 

setsigfflssk  (mask)  ;  /•  return  to  previous  mask  •/ 

) 

If  any  Ada  reserved  signal  other  than  SICALRM  or  SICVTALRM  is  to  be  similarly  blocked,  SICALRM  and 
SICVTALRM  must  be  either  already  blocked  or  blocked  at  the  same  time.  When  any  Ada  reserved  signal 
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other  than  SICALRM  or  SIGVTALRM  is  unblocked,  SICALRM  and  SICVTALRM  must  be  unblocked  at  the 
tame  time,  or  as  soon  as  possible  thereafter. 

Any  Ada  reserved  signal  blocked  in  interfaced  code  should  be  unblocked  before  leaving  that  code,  or  as 
toon  as  possible  thereafter,  to  avoid  unnecessarily  stalling  the  Ada  run-time  executive.  Failure  to  follow 
these  guidelines  will  cause  improper  delay  or  tasking  operation. 

An  alternative  method  of  protecting  interfaced  code  from  signels  is  described  in  the  Ada  User's  Guide  in 
the  section  on  "Execution-Time  Topica"  The  two  procedures  SUSPEND_ADA_TASKINC  and 
RESUME_^AOA_^TASKING  from  the  package  UNIX_ENV  supplied  by  HP  can  be  used  within  an  Ada  program 
to  surround  a  critical  section  of  Ada  code  or  a  call  to  external  interfaced  subprogram  code  with  a  critical 
section. 


F  14.8  Input'Output  From  Interfaced  Subprograms 

Using  I/O  from  interfaced  subprograms  written  in  other  languages  requires  caution.  Some  areas  in  which 
problems  can  arise  are  discussed  in  this  section. 


F  14.8.1  Files  Opened  by  Ada  and  interfaced  Subprograms 

An  interfaced  subprogram  should  not  attempt  to  perform  I/O  operations  on  files  opened  by  Ada.  Your 
program  should  not  use  HP-UX  I/O  utilities  intermixed  with  Ada  I/O  routines  on  the  ume  file.  If  it  is 
necessary  to  perform  I/O  operations  in  interfaced  subprogranu  using  the  HP-UX  utilities,  open  and  close 
those  files  with  HP-UX  utilities. 


F  14.8.2  Preconneetod  I/O  and  Interfaced  Subprograms 

The  standard  HP-UX  files  stdin  and  stdout  are  preconnected  by  Ada  I/O.  If  non -blocking  interactive 
I/O  is  used,  additional  file  descriptors  will  be  used  for  interactive  devices  connected  to  aid  in  or  atdout. 
Ada  does  not  preconnect  atderr,  which  is  used  for  run-time  error  messages.  For  more  details,  see  the 
section  on  Ada  I/O  in  the  LRM  and  the  section  on  using  the  Ada  Compilation  system  in  the  Ada  User's 
Manual 


F  14.8.3  Interactive  I/O  and  Interfaced  Subprograms 

The  default  I/O  system  behavior  is  NON-BLOCKINC  for  Ada  programs  with  tasking  and  BLOCKING  for 
sequential  (non-tasking)  Ada  programa  HP’s  implementation  of  Ada  sets  up  non-blocking  I/O  by  default 
on  interactive  files  if  the  program  contains  tasks  If  the  Ada  program  contains  no  task  structures  (that  is, 
it  is  a  sequential  program),  blocking  I/O  is  set  up  on  interactive  fiiea  You  can  override  the  defaults  with 
binder  optiona 

The  binder  option  -B  sets  up  blocking  I/O  and  the  binder  option  -b  sets  up  non -blocking  I/O.  In 
non-blocking  I/O,  a  task  (or  Ada  main  program)  will  not  block  when  attempting  interactive  input  if  data 
is  not  available.  In  that  case,  the  called  HP-UX  I/O  routine  returns  immediately  to  the  Ada  run  time 
(this  is  the  non -blocking  feature  applied  to  Ada  code  as  the  callerX  The  routine’s  return  allows  the  Ada 
run  time  to  place  the  task  that  requested  I/O  on  a  delay  queue,  and  to  awaken  the  task  when  the  I/O 
operation  is  complete.  This  arrangement  allows  other  tasks  to  continue  execution;  the  task  requesting  I/O 
will  be  delayed  until  the  I/O  operation  is  completed  by  the  Ada  run  time  (on  behalf  of  the  requesting 
task).  However,  if  you  set  up  non-blocking  I/O  on  external  called  subprograms,  the  effect  is  different. 


B-98 


Implementaticn -Dependent  Characteristics 

The  binder  (or  default)  options  set  or  clear  the  0_N0ELAY  flag  appropriately  (see  open  (2)  in  the  HP-UX 
Reference).  This  affects  both  Ada  I/O  and  HP“UX  I/O  operations.  For  more  information  about  Ada 
binder  options,  see  the  Ada  User's  Manual 

Attempting  interfaced  subprogram  input  from  the  preconnected  file  aid  in  can  produce  unexpected 
results  if  an  Ada  program  with  tasking  is  the  caller  of  the  external  subprogram.  In  this  situation,  since 
the  caller  is  a  tasking  program,  non-blocking  I/O  it  the  default  For  example,  consider  the  cate  of  an 
Ada  call  to  an  interfaced  C  subprogram  that  calls  the  HP-UX  subroutine  g«tchar(3}.  The  gotchar 
function  may  unexpectedly  receive  a  (-1)  result  because  no  character  may  be  available  on  atdin  at  the 
instant  the  call  is  made  since  non-blocking  I/O  is  in  effect 
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Certain  testa  In  the  ACVC  make  use  of  Implementation-dependent  values,  such 
as  the  maximum  length  of  an  Input  line  and  invalid  file  names.  A  test  that 
makes  use  of  such  values  is  identified  by  the  extension  .TST  in  its  file 
name.  Actual  values  to  be  substituted  are  represented  by  names  that  begin 
with  a  dollar  sign.  A  value  must  be  substituted  for  each  of  these  names 
before  the  test  is  run.  The  values  \ised  for  this  validation  are  given 
below. 


Name  and  Meaning _ 

$BIG_ID1 

Identifier  the  size  of  the 

msucimum  input  line  length  with 

varying  last  character. 

$BIG__ID2 

Identifier  the  size  of  the 

maximum  input  line  length  with 

varying  last  character. 

$BIG_ID3 

Identifier  the  size  of  the 

maxlmxim  input  line  length  with 

varying  middle  chauracter. 

$BIG_IDi< 

Identifier  the  size  of  the 

maximum  input  line  length  with 

varying  middle  character. 

$BIG_INT_LIT 

An  integer  literal  of  value  298 
with  enough  leading  zeroes  so 
that  it  is  the  size  of  the 
maximum  line  length. 


Value _ 

{1..254  s>  ’A’,  255  *>  M') 


(1..254  s>  'A',  255  =>  *2’) 


(1..127  I  129. .255  =>  ’A’,  128  s>  *3') 


(1..127  I  129. .255  =>  'A’,  128  =>  '4’) 


(1..252  =>  'O’,  253. .255  =>  "298") 
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Name  and  Meanlns 


Value 


$BIG_REAL_LIT 

A  universal  real  literal  of 
value  690.0  with  enough  leading 
zeroes  to  be  the  size  of  the 
maximum  line  length. 

$BIG_STRING1 

A  string  literal  which  when 
catenated  with  BIG_STRING2 
yields  the  Image  of  BIG_ID1. 

$BiG_STRING2 

A  string  literal  which  when 
catenated  to  the  end  of 
BIG  STRING 1  yields  the  Image  of 
BIG^IDI . 


(1..249  =>  '0»,  250. .255  a>  '•69.OEI") 


(1..128  a>  »A’) 


(1..126  s>  'AS  127  s>  '1') 


^BLANKS 

A  sequence  of  blanks  twenty 
characters  less  than  the  size 
of  the  maximum  line  length. 


$COUNT_LAST 

A  ~  universal 
literal  whose 
TEXT  10. COUNT ‘LAST. 


integer 
value  is 


(1..235  =>  •  •) 


2  147  483  647 


$FIELD_LAST 

A  ~  universal 
literal  whose 
TEXT  10. FIELD ‘LAST. 


integer 
value  Is 


$FILEJlAMEjaTH_BAD_CHARS 

An  external  file  name  that 
either  contains  invalid 
characters  or  is  too  long. 

$FILE_NAME_WITH__WILD_CARD_CHAR 

An  external  file  name  that 
either  contains  a  wild  card 
character  or  is  too  long. 

$GREATER_THAN_DURATION 

A  universal  real  literal  that 
lies  between  DURATION ‘BASE 'LAST 
and  DURATION ’ LAST  or  any  value 
in  the  range  of  DURATION, 


FILE  NAME  LONGER  THAN  14  CHARS/DIR  NOT  THERE 


not  there/»/*/»/not  there 


100  000.0 
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TEST  PARAMETERS 


Wane  and  Meanlr 


Value 


$GREATERjrHANJ)ORATION_BASE__LAST 

A  universal  real  literal  that  is 
greater  than  DURATION ‘BASE ’LAST. 

$ILLEGAL_EmRNAL_FILE_NAME1 

An  exteraal  file  name  which 
contains  Invalid  characters. 


100  000  000.0 


not  there/ /not  there/*' 


$ILLEGAL_EXTERNAL_FILEJJAME2 

An  external  file  name  which 
is  too  long. 

$INTEGER_FIRST 

A  universal  integer  literal 
vdiose  value  is  INTEGER 'FIRST. 


not  there/not  there/not  there/ ./. /not  there/// 


-2147483647 


$INTEGER_LAST 

A  universal  integer  lltered 

whose  value  is  INTEGER 'LAST. 

$INTBGER_LAST_PL0S_1 

A  universal  integer  literal 
whose  value  is  INTEGER 'LAST  +*  1. 


2147483647 


2  147  483  648 


$LESS_THANJ)URATI0N 

a""  universal  real  literal  that 
lies  between  DURATION 'BASE 'FIRST 
and  DURATION 'FIRST  or  any  value 
in  the  range  of  DURATION. 

$LESS_THAN_DURATION_BASE_FIRST 

A  universal  real  literal  that  is 
less  than  DURATION 'BASE 'FIRST. 


-100  000.0 


-100  000  000.0 


$MAX_DIGITS 

Maximum  digits  supported  for 
floating-point  types . 

$MAX_IN_LEN 

Maximum  input  line  length 
permitted  by  the  implementation. 

$MAX_INT 

A  universal  integer  literal 
whose  value  is  SYSTEM. MAX  INT. 


2147483647 


$MAX_INT_PL0S_1 

A  universal  integer  literal 
;diose  value  is  SYSTSM.MAX  INT+1. 


2  147  483  648 
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TEST  PARAMETERS 


Mane  and  Meanlr 


Value 


$MAX_LEN_INT_BASED_LITERAL 

A  universal  Integer  baaed 
literal  trtiose  value  Is  2#11# 
with  enough  leading  zeroes  In 
the  mantissa  to  be  MAX_IN_LEN 
long.  “  ” 

$MAX__LEN_REAL_BASED_LITERAL 

A  universal  real  based  literal 
;^ose  value  Is  16:F.E:  with 
enough  leading  zeroes  In  the 
mantissa  to  be  MAX__IN_LEN  long. 

$MAX_STRIMG_LrrERAL 

A  string  literal  of  size 
MAX_IN_LEN,  Including  the  quote 
characters . 


(1..2  s>  "2:",  3. .252  =>  'O',  253. .255  =>  "11:") 


(1..3  =>  "16:",  4. .251  =>  'O’,  252. .255  =>  "F.E; 


(1  1  255  s>  2.. 254  =>  'A') 


$MIM_INT 

A  universal  Integer  literal 
whose  value  is  SYSTEM .MIN  INT. 


-2147483647 


$MAME 

A  name  of  a  predefined  numeric 
type  other  than  FLOAT,  INTEGER, 
SHORT  FLOAT,  SHORT  INTEGER, 
LONGJlOAT,  or  LONG^INTEGER. 

$NEG_BASED_INT 

A  based  Integer  literal  whose 
highest  order  nonzero  bit 
falls  in  the  sign  bit 
position  of  the  representation 
for  SYSTEM. MAX  INT. 


SHORT  SHORT  INTEGER 


16#FF  FF  FF  FD# 


APPENDIX  D 


WITHDRAWN  TESTS 


Some  tests  are  withdrawn  from  the  ACVC  because  they  do  not  conform  to  the 
Ada  Standard.  The  following  27  teats  had  been  withdrawn  at  the  time  of 
validation  testing  for  the  reasons  Indicated.  A  reference  of  the  form 
"Al-ddddd"  Is  to  an  Ada  Commentary. 


.  B28003A:  A  basic  declaration  (line  36)  Incorrectly  follows  a 

later  declaration. 

.  E28005C:  This  teat  requires  that  "PRAGMA  LIST  (ON);"  not  appear 

In  a  listing  that  has  been  suspended  by  a  previous  "PRAGMA  LIST 
(OFF);";  the  Ada  Standard  Is  not  clear  on  this  point,  and  the 
matter  will  be  reviewed  by  the  AJPO. 

.  C34004A:  The  expression  in  line  168  yields  a  value  outside  the 

range  of  the  target  type  T,  but  there  Is  no  handler  for 
CONSTRAINT_ERROR. 

.  C35502P:  The  equality  operators  In  lines  62  and  69  should  be 

inequality  operators. 

.  A35902C:  The  assignment  in  line  17  of  the  nominal  upper  bound  of 

a  fixed-point  type  to  an  object  raises  CONSTRAINT__ERROR,  for  that 
value  lies  outside  of  the  actual  range  of  the  type. 

.  C35904A;  The  elaboration  of  the  fixed-point  subtype  on  line  28 

wrongly  raises  CONSTRAINT__ERROR,  because  its  upper  bound  exceeds 
that  of  the  type. 

.  C35904B:  The  subtype  declaration  that  is  expected  to  raise 

CONSTRAINT_ERROR  when  its  compatibility  is  checked  against  that  of 
variovis  types  passed  as  actual  generic  parameters,  may,  in  fact, 
raise  NUMERIC_ERROR  or  CONSTRAINT_ERROR  for  reasons  not 
anticipated  by  the  test. 


WITHDRAWN  TESTS 


.  C35A03E  and  C35A03R:  These  tests  assume  that  attribute  'MANTISSA 

returns  0  wh«n  applied  to  a  fixed-point  type  with  a  null  range, 
but  the  Ada  Standard  does  not  support  this  assumption. 

.  C37213H:  The  subtype  declaration  of  SCONS  in  line  100  is 

incorrectly  expected  to  raise  an  exception  when  elaborated. 

.  C37213J:  The  aggregate  in  line  451  incorrectly  raises 

CONSTRAINT_ERROR. 

.  C37215C,  C37215E,  C37215G,  and  C37215H;  Various  discriminant 

constraints  are  incorrectly  expected  to  be  incompatible  with  type 
CONS. 

.  C38102C:  The  fixed-point  conversion  on  line  23  wrongly  raises 

COMSTRAINT^ERROR. 

.  C41402A:  The  attribute  'STORAGE_SIZE  la  incorrectly  applied  to  an 

object  of  an  access  type. 

.  C45332A:  The  test  expects  that  either  an  expression  in  line  52 

will  raise  an  exception  or  else  MACHINE_OVERFLOWS  is  FALSE. 
However,  an  implementation  may  evaluate  the  expression  correctly 
using  a  type  with  a  wider  range  than  the  base  type  of  the 
operands,  and  MACHINE^OVERFLOWS  may  still  be  TRUE. 

.  C45614CI  The  function  call  of  IDENT_INT  in  line  15  uses  an 

argument  of  the  wrong  type. 

.  A74106C,  C85018B,  C87B04B,  and  CCI31IB:  A  bound  specified  in  a 

fixed-point  subtype  declaration  lies  outside  of  that  calculated 
for  the  base  type,  raising  CONSTRAINT  ERROR.  Errors  of  this  sort 
occur  at  lines  37  4  59,  142  &  143,  T6  4  48,  and  252  4  253  of  the 
four  teats,  respectively. 

.  BC3105A:  Lines  159  through  168  expect  error  messages,  but  these 

lines  are  correct  Ada. 

.  AD1A01A:  The  declaration  of  subtype  SINT3  raises  CONSTRAINT^ERROR 
for  implementations  which  select  INT'SIZE  to  be  16  or  greater. 

.  CE2401H;  The  record  aggreg;atea  in  lines  105  and  117  contain  the 

wrong  values. 

.  CE3208A:  This  test  expects  that  an  attempt  to  open  the  default 

output  file  (after  it  was  closed)  with  mode  IN  FILE  raises 
NAME_ERROR  or  USE^ERROR;  by  Commentary  M-00048,  MODE^ERROR  should 
be  raised. 
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